Omnimaga
Omnimaga => News => Topic started by: DJ Omnimaga on March 28, 2013, 10:37:17 pm
-
Just now, tr1p1ea has posted the following video on Youtube and OmnomIRC:
This video shows a TI-84 Plus C Silver Edition tile-mapper, featuring scrolling, in the 160x240 resolution mode that Calc84maniac recently discovered (http://ourl.ca/18523). The speed result is very promising! The sprites used in the video are 8x8, with their height scaled up to 16 pixels, but since the calculator is set to 160x240 instead of 320x240, the sprites looks as large as their height.
Hopefully an ASM library that allows TI-BASIC programmers to change the horizontal screen resolution and the display starting position (z-adress) will also be released in the near future, so that those programmers can take advantage of that Atari/Commodore-like mode too!
(http://img.removedfromgame.com/imgs/160pscreentest.png)
This means that fast-paced side scrollers should be very easy to create on Texas Instruments' newly released color calculator.
-
/me feels honord by being mentioned in that screenie
/me lost
/me thinks it is awesome and this little feature may get him to buy a CSE after all as it s so quick O.o
/me notices that his message only consists out of /me messagges
-
Note that the scrolling in that video doesn't involve drawing any pixels, by the way. It'll be a bit slower if you want to have a play area wider than two screen widths, since you'll have to actually draw in the new tiles. Should still be relatively fast, though.
-
The test doesn't do any drawing but it also only processes every 16th frame so there is room to play possibly.
-
The test doesn't do any drawing but it also only processes every 16th frame so there is room to play possibly.
I keep wondering, what exactly is a "frame" here. I mean, if all you're doing is changing the scroll registers you can probably get over 9000 FPS, but that doesn't really affect the display which has its own frame rate.
-
Lol I was reluctant to use the word frame because it isn't really correct. Basically instead of scrolling every loop I only change x every 16 loops. The registers are still written to every iteration tho ... just wanted a quick delay *hides*
-
Do you think you could do a video showing scrolling where an entire column of tiles is updated every frame? I am curious about how fast it would be. TO make it more accurate, add a Mario sprite, along with 3 enemies and a shroom in the mix, using masking for all.
-
Nice job with the tests.
So does that mean that the 84 CSE games will have levels that are just super-sized images that are zoomed in and scrolled, and the sprites are moved on them?
-
That's very nice !
So that's basically GBA resolution. Not bad at all ! I hope we can write fast enough tile map renderers. :)
Do we have that extra space on the vertical axis (for RPGs) ?
-
you should be able to make arbitrary sized buffers regardless, but the hardware doesnt support vertical scrolling the same way it does horizontal scrolling shown in the video. Vertical scrolling will be slower.
-
Arf that's too bad I got oversized hope. :(
-
That's pretty cool. Hope lots of GBA-like games gets developed :P
-
Can it also repeat the image and stitch the ends together?
-
Can it also repeat the image and stitch the ends together?
Yep, that's exactly what happens. If you draw tiles offscreen before you reach them, you can pretty much scroll infinitely in the horizontal direction.
-
It doesnt look like it though. You see that it's just one image, but it's stretched out to fill multiple screens. You can only scroll within the boundaries of the image in this demo.
-
He probably did that on purpose to avoid scrolling too far in the video.
-
Will there be any on calculator programming for this?
-
Well, you have BASIC right out of the box.
-
And Basic can do this?
-
Pretty cool. The “half horizontal resolution” mode doesn't look bad at all.
This reminds me that the classic consoles such as the NES actually were quite limited on how many tiles could be updated per frame. They took advantage of having an extra screen-sized buffer, just as in this example (some games didn't even use that) to update rows or columns of tiles off-screen just before they scrolled into view. In this case, there is no direct hardware support for sprites; those would still need to be directly drawn, but if that can be done fast enough, this certainly does look promising, framerate wise. The biggest key here will be how many pixels can be updated per frame, and how much CPU time will be needed by AI and logic.
-
@Augs:No. That demo is written in asm on a pc.
-
And Basic can do this?
Since the calc is as fast for math calculations as the 84+SE (only graphics/drawing are slower), I wouldn't be surprised if such speed could be rivaled using ASM libs in a BASIC program (such as xLIB 2?). It wouldn't be as fast with collision detection, of course, but it could be a good alternative to just updating the entire screen every frame.
But yeah, the calc isn't locked down in any way in terms of programming. Of course now you're stuck with a Mathprint OS, but otherwise for programming this calc is an huge contrast with the stance TI took against Ndless on the TI-Nspire.
-
It's sad how long it takes to actually draw everything before the scrolling :( Still, great discovery! If only the vertical part could be cut in half as well!
By the way, what are scrolling registers?
-
To be honest I am surprised that the drawing before scrolling is that slow. It seems to me that it's not super optimized or it runs at 6 MHz. Kerm made a demo program once that could redraw the entire screen 4 times a second.
-
Tr1p1ea made a larger map video now:
Notice how the speed barely changes, except some minor stuttering when it reaches the edge of the screen. Delay had to be removed but speed still looks good. :D
I would like to see a video using 8x16 tiles instead, though, so that it shows its full possible 160x240 res rather than 160x120.
-
Oops i updated the link to the video to remove the screen artifacts. It can be seen here:
-
Looks very nice :)
-
That does look really nice! How much space does all the data take up?
EDIT: Or is the source posted anywhere?
-
The data takes up a bit of space. The map is 168x15 = 2520 bytes. There are 71 8x8 tiles that use 4-bit palette indices packed into nibbles, so its 32 bytes per tile = 2272 bytes.
-
Is it archived while read?
-
Since this is only a test it isnt archived, however i have made an image viewer that can read puCrunched 16-colour images from archive.
-
Since this is only a test it isnt archived, however i have made an image viewer that can read puCrunched 16-colour images from archive.
Pr0n? O.O
Just kidding, but I remember that Final Fantasy girl pic on calc you posted back in the days :P
-
I suspect JPEG image decompression is do-able, although it wouldn't be fast, of course.