30 replies to this topic

[KingofGamesYami]

Code.

Currently, I'm trying to debug my blit function, which is weirdly erroring on line 51 with 'attempt to index ? (a nil value)'. I've proven that internalText exists, and that internalY is always 1. Strangely enough, it errors on the 5th call, not the first.

[moTechPlz]

Not sure if this is the culprit but the code increases the string length by one.

local internalX, internalY, internalText = 5, 1, {}

internalText[ internalY ] = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
text = "blabla"

print( internalText[ internalY ] )

internalText[ internalY ] = internalText[ internalY ]:sub( 1, internalX ) .. text .. internalText[ internalY ]:sub( internalX + #text )

print( internalText[ internalY ] )

Edited by moTechPlz, 23 March 2016 - 05:40 PM.

[KingofGamesYami]

I thought that was an issue, the problem is I gotta figure out where to change the :sub. Also, that wouldn't cause an attempt to index error, since it doesn't set anything to nil. There's doubtlessly many more issues I need to fix, I just need it to run before I can fix those.

Edited by KingofGamesYami, 23 March 2016 - 05:59 PM.

[Dragon53535]

When you say it happens on the 5th call, are you calling anything else in between that?

[Dog]

While this isn't the problem you're looking for, I was wondering if line 133 is intentional - it currently sets getTextColour equal to getBackgroundColor

[KingofGamesYami]

Well, the way I'm testing is by redirecting to it and then shell.run(ing) the paint program. So, maybe? I looked at every instance of the variables involved, and I can't find a single instance where they would be nil - and it never outputs nil either. The only reason I know it's the fifth call is it prints my debug things to the native terminal 5 times before that.

Dog, on 23 March 2016 - 07:33 PM, said:

While this isn't the problem you're looking for, I was wondering if line 133 is intentional - it currently sets getTextColour equal to getBackgroundColor

Thanks for pointing that out, fixed. Not intentional, as I said before I need to do a lot of testing - once this runs without outright erroring.

Edited by KingofGamesYami, 23 March 2016 - 07:34 PM.

[Dog]

Again, not the problem, more of a question if you will...

I noticed in your update function (specifically lines 30 and 34) that you have two loops (one nested inside the other), both using y as a variable. How does the code within the nested loop know which y value to use?

[Dragon53535]

It uses the most local y, so it's own. The one above it isn't used. Since the first y is the index of the monitor, I don't think he cares.

Edit: Wait, wait, why is tMonitors a nested table? Shouldn't it just be a table full of wrapped monitors?

Edited by Dragon53535, 23 March 2016 - 07:52 PM.

[Dog]

Thanks, Dragon

I *think* tMonitors tracks the stitched monitors, so each tMonitor entry has a table of multiple monitors within it.

Edited by Dog, 23 March 2016 - 07:58 PM.

[KingofGamesYami]

tMonitors is indeed nested tables, I have 6 monitors attached to it. I have it set up so that it's visually similar to the physical placement:

local tMonitors = {
  { <1,1>, <2,1>, <3, 1> },
  { <2,1>, <2,2>, <3, 2> },
}

Yeah I don't care about the y value in the upper loop, it's not used. I could change it, but I'm using it to remember how the layout of my table structure is.

Edit: actually, I'm messing with the update() code in game right now, it's rendering everything 1 character to the right at the moment (or maybe that's the buffer?)

Edit #2: I think the above is related to that

Edit #3: Fixied!

[b]Note: I am editing the paste I posted in the OP frequently.

Edited by KingofGamesYami, 23 March 2016 - 08:12 PM.

[Dragon53535]

Would you mind adding this line like right above 51?

term.native().write(internalText[internalY])

That way we can check if it's erroring on internalText being nil, or that specific spot.

Edited by Dragon53535, 23 March 2016 - 08:09 PM.

[KingofGamesYami]

Did that, and...



Dafuq?

[KingofGamesYami]

Progress:

[Creator]

That looks epic!

[KingofGamesYami]

Hmm.. Now mon.blit is erroring with 'arguments must be the same length' (this is on line 42 in the paste). I'm not sure how the arguments would ever be different lengths, since I'm using the same string.sub on all of them.

[Dragon53535]

It looks like you're having a too long without yielding error.

Edit: Guess I got ninja'd by you confirming lol

Edited by Dragon53535, 23 March 2016 - 11:22 PM.

[KingofGamesYami]

Fixed all the bugs, now optimization is needed. I'm getting too long without yielding 3/4ths of the way through a monitor with the text scale set to 0.5, so I'm going to try and cache as much as possible.

Update: Now getting to second row before too long without yielding error. Progress!

Edited by KingofGamesYami, 23 March 2016 - 11:36 PM.

[Bomb Bloke]

stitch.write() will need to tostring "text".

Shouldn't clearLine() / scroll() call update()?

stitch.blit() needs to ensure the text is in bounds. It'll need to crop it if one of the ends will poke off the left / right of the display, or entirely ignore it if it won't be visible at all.

[KingofGamesYami]

Added tostring

Yes they do, fixed.

That's going to hurt performance. *smashes head against wall*. What would be the most efficient way to do this? I'm not entirely certain I need to do that at all, won't mon.blit cut it for me?

[Bomb Bloke]

write() still isn't using tostring() correctly. When calculating the length of the textColour string for eg, you can't very well base that on a nil value. Try passing it some numbers or other data types to see what I mean.

KingofGamesYami, on 23 March 2016 - 11:48 PM, said:

What would be the most efficient way to do this? I'm not entirely certain I need to do that at all, won't mon.blit cut it for me?

Hah, no, mon.blit() isn't going to help you. When you only want to add part of the incoming text to your buffer, you're going to have to specify that.

The window API has an example of how you might go about doing it, and is about as efficient as you'll get.

https://github.com/a...pis/window#L103

In terms of optimising the rest of your code, cache table lookups - if you're going to index into the same position multiple times, do it once, assign the value to a new local, and then refer to that from then on.

Also cache table lengths and rep'd strings, and avoid select().

Edited by Bomb Bloke, 24 March 2016 - 12:12 AM.