[Ti-83plus Asm Games] Rush Hour: Greyscale

[WikiGuru]

File Name :: Rush Hour: Greyscale
Author :: WikiGuru
Category :: Ti-83plus Asm Games
Screenshot :: [img]http://www.unitedti.org/index.php?act=downloads&do=imgss&id=325[/img]
Description ::
Based on the popular Binary Arts game. The goal is to free your car (the one that doesn't look like the others) from the ramble of the grid by moving the other cars and trucks.
Featuring 40 maps, 4-level RGP greyscale for the cars and trucks, an 8-way scrolling greyscale cursor, external level support, an on-calc level editor, and much more!
Runs under MirageOS
Update: Version 1.3 features flash archive support, and an all new compatibility with the new Rush Hour level editor (included)!
Update: Version 1.2 features an all new splash screen designed by UTI members and external level support!

Updated Mon, Jul 14 2008 7:44 pm

View File

[cjgone]

Dang, nice game! :D

Arrow unalligned?? Just wondering how'd you do that... a modulus 8 (and 07) to get a specific square for both x and y?

[WikiGuru]

yeah, that's the basic jist of it. I basically modified ionputsprite for my needs

[cjgone]

haha. Nice game, keep up the good work.

[luby]

I still notice that initial flicker, but other then that, It looks great. Nice Job!

[simonzack]

Great work! Keep it going

[WikiGuru]

yeah, I didn't really have a great way to draw the grescale. I just quickly switched between two sprites, but this meant I had to redraw the tilemap everytime. If someone has a better way, I'd be happy to implement.

[TheStorm]

well what you should do is not update the display until you have drawn to both buffers and then update the display and enable the grayscale interrupt.

[cjgone]

[TheStorm]

Because it isn't that hard to do your self. You are just drawing each sprite twice and then switching buffers.

[WikiGuru]

I was debating that for a while. I don't know if the size trade off is worth it, though. what do you think?

[TheStorm]

I personally think it is fine as it is. I also feel the SE version is unneeded. I just use the BE version so I can send it to others without having an issue.

[cjgone]

Dunno how much it flickers..
But if it doesn't flicker to much, it won't be a problem... However, if you're dieing to have perfect grayscale + 2500 extra bytes (around 1800 if you toss half of graylib.inc), then it might be worth it....


You could also just use XOR draw routine and call it in an interrupt so it deletes the pic again\ redraws it.... leaving a greyscale affect. (the specific sprites)


honestly, i don't know how many layers of grey you have? 3 shades or 4?

[WikiGuru]

Umm, I'm not sure how you would 'classify' greyscale, but there's white, 1 shade of grey, and black. I suppose it's kind of pitiful. The reason it takes so long is because of the tiling routine. It re-tiles everytime to save space. I suppose it might be worth it to use saferams, though. If I can find another 768 bytes (in addition to plotsscreen) not used by MirageOS...

@TheStorm: It's okay if you do it the other way around (supposedly). The only function not completely supported in the BE is fast mode. On the TI-83+ BE it only modifies the shadow link port, and I'm told that it shouldn't be a problem if you don't use the link cable at the same time.

[luby]

*cough*
*cough*AppBackupScreen
*sneeze*
*sigh*

[Liazon]

you can just dynamically allocate the 2*768 bytes for RGP @ $9D95, and then use NODOUBLEBUFFER mode so you don't have to use saferams (plotscreen and savescreen for RGP)

it's important to note that your buffers MUST be adjacent to each other in memory when using RGP, which is why you can't use saferams for the main buffers, only the back buffers. RGP uses optimizations that rely on the fact the two buffers are next to each other. that's why by default, the buffers are a giant block in your program, which is why I'd advise you to use _insertmem and _delmem to allocate at $9d95.

hope that helps.

for the most part RGP looks pretty good on a good 83+BE, but on bad 83+BE, the flicker is unavoidable. it's possible that the flicker you experienced with your gs may be because of the LCD controller, but I could be wrong.

[TheStorm]

You can get 4 level grayscale (white, gray, dark gray, black) with 2 buffers and that is all you truly need. If you have more than that I feel it is just bloat.

[WikiGuru]

@thestorm: how do I get 4-level greyscale? as far as i can tell, here are my options (with 2 buffers):
In sprite data:
1 1 (black)
0 0 (white)
1 0 (grey)
0 1 (same color grey)

How do you get the grey and dark grey given 2 buffers?

@Liazon: Probably a stupid question, but why did you choose $9D95 (I haven't quite memorized all the RAM equates, if any)? Also, why do the buffers have to be right next to each other? Convenience of the programmer? actual speed/size benefits? other reasons?

@Luby: I think that's a good idea, I hope. I'm not sure, but I remembered reading somewhere that MOS (or another shell, i might have gotten them confused) used the first few bytes of Appbackupscreen. Am I right at all, or is there something or a lot of things wrong with this statement?

Btw, thanks for all your guy's help! This will really make the next update (when I get time) much better than I could have by myself.

[TheStorm]

You display one buffer longer than the other. Lets say two thirds of the time. and the other one 1 third of the time. So it would end up as
1 1 black
0 0 white
1 0 dark gray
0 1 light gray
that is if the first buffer is the one you display for longer

[WikiGuru]

ohh, i get it. That makes sense now. :blush:

wait, but if you're displaying one sprite longer then the other, you can't really have a flicker-less dark grey (or light grey) block, can you? It will flicker because of the coherent properties of having a section of the screen switch colors together instead of in a checkerboard pattern.