Omnimaga
Calculator Community => Other Calculators => Topic started by: calc84maniac on March 16, 2013, 05:28:48 pm
-
I just made an awesome discovery. It's possible to effectively halve the horizontal resolution of the screen on the TI-84+CSE, while still filling up the entire area of the screen, which means asm game programmers can double their framerate at a small visual cost.
(http://i.imgur.com/JClETGq.jpg)
This will even allow for double-buffering, where you draw to the offscreen area and then swap it in instantly, preventing flickering. My method uses partial images and interlaced output.
More detailed information on how to implement:
Enable two partial images, where one is displayed at column 0 and the other is displayed at column 160. Both partial images should be set to the same 160 columns of GRAM which you want to display. (When enabling the partial images, disable the base image.) Then turn on interlaced output (bit 10 of register 1).
-
Wow! Great discovery! Can I ask how you discovered this?
-
Wow! Great discovery! Can I ask how you discovered this?
I was just messing around with the LCD controller and I enabled interlaced mode, and it was different than I expected, in a good way. It basically outputted the first 160 columns of GRAM on the even columns of the LCD and the last 160 columns of GRAM on the odd columns of the LCD. Combining that with partial images produced magic :)
-
Interlacing? Well that's pretty cool.
-
That is pretty awesome!/me wants a cse now :P
-
This also means something I thought was possible is MORE possible!!!
A ti-84 emu can be made easily now because the screen res can be made compatible!
-
/me suddenly desires a CSE because theoretically, this could be used to double, maybe even quadruple (if we can figure out how to add on to this feature, perhaps a quad sized screen?) framerates and thus have a legit game with nice graphics, like, ohhhh, say a port of SMB? :)
-
Darn that will be handy for certain type of games. Of course not for games that requires accurate sprite details, but for others it will be fine :D.
Actually using this for Shoot-em-ups will be like Atari 2600 games :P
-
Awesome find! I may need to incorporate this in some way with MicrOS.
-
ooh, brilliant!
that's quite the motivator for making things =)
-
Interesting, indeed :)
And perhaps there's more to be discovered about the LCD controller.
-
By the way, is it possible to change the screen start to something else than 0 and 160? Because if it could be used in TI-BASIC via an ASM lib, you could set the screen just so that the drawable graph screen area takes the entire LCD width, then BASIC coders could simply use that 160x165 area to draw stuff. (eg vertical/horizontal sprites)
-
By the way, is it possible to change the screen start to something else than 0 and 160? Because if it could be used in TI-BASIC via an ASM lib, you could set the screen just so that the drawable graph screen area takes the entire LCD width, then BASIC coders could simply use that 160x165 area to draw stuff. (eg vertical/horizontal sprites)
Well, the partial display window output positions should always be 0 and 160 due to how the display interlacing works, but the GRAM that you display can be any 160 consecutive columns, yes. (You can even wrap around from the right side to the left side of GRAM, which means horizontal scrolling tricks are still possible.)
-
Do you mean that with Z-adress you could actually achieve my trick?
By the way this is what I mean in case someone else don't understand:
(http://img.removedfromgame.com/imgs/160pscreentest.png)
-
Yep, you can choose any 160-pixel wide area of the screen and extend it.
-
Cool to hear :D. 20x14 sprites will be handy :D (or of course in the case of text sprites any size, but won't take as long to render).
-
So, basically you're still using the full 320 horizontal resolution(with interlacing I mean), you're just updating half of it at once.
-
2 wide pixels? commodore 64 emulator, anyone?
-
I just checked Google and the Atari 2600 resolution for NTSC systems appears to be 160x192. So basically with a 160x240 or 160x165 resolution we'll most likely have games that looks similar to the Commodore 64 :P
-
Calc84maniac, do you think you could release a 8xp program for BASIC programmers allowing them to change the screen position and resolution directly from BASIC programs? You could put the program in Omni archives along with ticalc.org ASM misc programs:
If X=1, it would change resolution to 160x240.
If X=Anything else, it would change resolution to 320x240.
Ans would contain the screen position (which I assume would be 0 to 319 in 320x240 mode and 0 to 159 in 160x240 mode). So basically the syntax would be something like this (kinda like other libraries):
1->X:159:Asm(prgmZSCRNRES
-
I just checked Google and the Atari 2600 resolution for NTSC systems appears to be 160x192. So basically with a 160x240 or 160x165 resolution we'll most likely have games that looks similar to the Commodore 64 :P
Yeah... C64 had 2 modes: 320x200 & 160x200. ;)
-
Just did a quick mockup of what a game could look like at 160x240 resolution using the full color depth of the calculator and it definitively doesn't look bad:
(http://img.removedfromgame.com/imgs/rol0csemockup.png)
And of course for side scrollers, you just have to make the HUD as minimal as possible then shift the screen starting position to scroll around. There might be some shaking occuring during scrolling for the HUD before it gets updated to its appropriate position, but it would be much faster to display 8x16 sprites than 16x16.
-
Tile by tile scrolling wouldn't be that bad, either.
-
True, although for a Mario game this might be annoying to play D:
-
Not all action games need smooth scrolling, though. You could make a pretty decent platformer on one screen if you were willing to go for a smaller character.
What kind of LCD controller does the CSE use, anyway? I'm curious now.
-
True. Although I think a lot of action games based on platformers might require smooth movements to prevent hindering gameplay. For example, try to play Sonic the Hedgehog at 4-8 frames per second while still being able to control Sonic properly. :P
Also besides 160x240 resolution, since the speed bottleneck is really drawing to the LCD, you could sacrifice display quality further by using 160x120 mode instead. In 160x120 mode, however, you would need to only update every 2 line of pixels on the screen to gain speed at all:
(http://img.removedfromgame.com/imgs/drawingevery2lineofpixel.png)
It may not look super nice, but since pixels are kinda small, it might not be that bad either. Some graphics might sometimes need to have higher contrast so it's not too dark, but this would not be the first time that such technique is used in games, since some old computers did as well.
In the example above, you could go further by using interlacing as well, alternating between odd and even line rows every frame.
In the case where someone would still want to use 160x240 with such technique, interlacing or moving scanlines would be necessary.
So basically, to update the entire game area for vertical scrolling, speed would max out at the following values:
320x240: 4 FPS
320x240 interlaced: 8 FPS
320x120: 4 FPS
320x120 drawing every 2 line: 8 FPS
160x240: 8 FPS
160x240 interlaced: 16 FPS
160x240 scanlines: 16 FPS (might be annoying for the eyes)
160x120: 8 FPS
160x120 drawing every 2 line: 16 FPS
Scanline mode would be kinda useless because it would require shifting the LCD position back and forth between 0 and 160, so you might as well go with interlaced mode. Plus I am unsure if many people would like if their games looked like this:
(http://img.removedfromgame.com/imgs/interlacedrolexample.gif)
On a Nspire CX it would be so fast that it would look smoother but on the slower 84+CSE that's how fast the scanlines would alternate.
Then there is also the Starwing/Star Fox and Stunt Race FX trick on the SNES: Not using the entire screen for the game. If you play Star Fox for the SNES, notice how there's a big black frame surrounding the gameplay area. Gemini for the 83+ did that too.
-
Note: Taking screenshots from TI ScreenCapture in 160x240 mode is impossible: It either is unable to detect your calc or it throws up an error after 30 seconds of wait.
-
Personally, I think the non-moving scanlines look quite good. However, that animated one won't look good at all, mostly due to the fact that, like our computer screens, the 84+CSE has an active LCD matrix. (I think. Most color LCDs are, but some older ones weren't and you never know with TI :P)
-
For some reasons my last post vanished...
To sum things up, what I noticed is that on the CSE the scanlines are vertical instead of horizontal, so it's possible that it wouldn't affect the display methods above. The screen, unlike on the Game Boy Advance and TI-Nspire CX, was rotated 90° inside the calc it seems.
-
To sum things up, what I noticed is that on the CSE the scanlines are vertical instead of horizontal, so it's possible that it wouldn't affect the display methods above. The screen, unlike on the Game Boy Advance and TI-Nspire CX, was rotated 90° inside the calc it seems.
KermM figured that out long ago based on the datasheet for the driver, which is specifically designed for portrait-orientation LCDs. Hence why the WikiTI page on the LCD has this warning:For those following along with the data sheet: Like before, the X/Y plane is flipped in the data sheet documentation. Specifically, the the screen is rotated 90 degrees from the way the manufacturer expects, so "horizontal" and "vertical" refer to the OTHER, i.e. horizontal means up and down on the screen. Also, "up" and "down" are switched with "left" and "right".
This is also why we select interlaced mode for the double-width pixels hack. If the controller scanned the other way, it would generate double-height pixels.
-
Yeah I know, I was responding to willrandship's concern about horizontal scanlines being produced by the LCD.
By the way, will the vertical LCD make it harder to display sprite data? Will the sprite binary/hexadecimal data have to be rotated in ASM/Axe source code in order to display fine?
-
Yeah I know, I was responding to willrandship's concern about horizontal scanlines being produced by the LCD.
By the way, will the vertical LCD make it harder to display sprite data? Will the sprite binary/hexadecimal data have to be rotated in ASM/Axe source code in order to display fine?
Data can be displayed in either direction, but displaying vertically will likely be easier due to only needing 8-bit coordinates for the output window. Also, displaying vertically is pretty much a must for games that abuse horizontal scrolling if the sprites are going to wrap around GRAM properly.
-
I guess what Axe could do to accomodate people used to the older models is to have a conversion mode that rotates data as an option, for those who don't want to redo their entire sprite work from scratch.
By the way calc84maniac did you check if 160x240 works in Tilem/jsTIfied?
-
TilEm does support 160x240 mode, yes. Most of the documented LCD controller features are supported at this point; some of the undocumented features still need to be tested.
As far as sprite orientations are concerned: in most cases, you should be able to store the sprite in whatever orientation you like, and flip/rotate it by switching the output mode as desired. As for the case of wrapping around that calc84maniac mentions: that's one of the undocumented features I still need to explore. :)
-
TilEm does support 160x240 mode, yes. Most of the documented LCD controller features are supported at this point; some of the undocumented features still need to be tested.
As far as sprite orientations are concerned: in most cases, you should be able to store the sprite in whatever orientation you like, and flip/rotate it by switching the output mode as desired. As for the case of wrapping around that calc84maniac mentions: that's one of the undocumented features I still need to explore. :)
Actually, for the wrapping around, I'm referring to having a window of (y1,y1+height-1) and (0,319). If you draw vertically, you'll wrap around after 319 (not undocumented at all). However, from what I saw on the SVN, you may not be clipping LCD coordinates to 8-bits or 9-bits upon write. Any bits listed as 0 in the data sheet is forced to 0 (i.e. writes are ignored). This should be useful for some code optimizations, I think.
-
Actually, for the wrapping around, I'm referring to having a window of (y1,y1+height-1) and (0,319). If you draw vertically, you'll wrap around after 319 (not undocumented at all).
Ah yes, good point.
However, from what I saw on the SVN, you may not be clipping LCD coordinates to 8-bits or 9-bits upon write. Any bits listed as 0 in the data sheet is forced to 0 (i.e. writes are ignored). This should be useful for some code optimizations, I think.
Ooh, excellent observation, you're right, I forgot to do that (although, for most of the registers, it shouldn't make any difference in practice.) This also suggests an obvious test for undocumented registers/bits, and indeed there are several:
- R04 (undocumented on 9335) has the significant bits 0777. (On the 9325 this is the "resizing control" register and ought to have significant bits 0333. So maybe the 9335 allows resizing after all, and maybe it even has more modes than the 9325? On the 9221 this is one of the two comparison registers and should have significant bits 3F3F.)
- R05 (as documented) has the significant bits 0003, though as I've noted elsewhere it doesn't seem to have the documented effect. (On the 9221 this is the other comparison register and should have significant bits 003F.)
- R06 (not documented anywhere that I know of) has the significant bit 0001.
- R10 has the significant bits 1717; according to the docs it should be 17F3. (edit: not true, it's just that reading registers doesn't work correctly when the STB bit is set.)
- All of RE2-REF, RFE, and RFF have some significant bits; of these, only RE6 is documented.
-
R04 definitely does something. Here's a fun utility you can play with. It's like the Calcsys port monitor, but for the LCD.
Writing to many of those undocumented registers causes the screen to go haywire.
-
Indeed. The only way I've found to exit "panic mode" is to toggle STB on and off (maybe SLP would work as well.) I think this is the controller's way of saying it doesn't like what you're doing.
It seems that it does indeed have a resizing function, but it doesn't work reliably (sometimes it works correctly, sometimes it draws a few pixels and then panics. Something to do with timing, I guess.) I'm not sure exactly what all the resizing modes are doing, but all 7 modes are down-scaling. And when they do work, they apparently work by simple resampling (dropping pixels, not doing any sort of averaging), so it really is a basically useless feature.
-
I can't wait for calcsys for CSE's... Or for somebody to compile calcsysX lol
So now my list of calcs to buy: Prizm, 89, 86, Classpad, CSE, old Nspires. In no particular order.
-
What is this calcsysX I keep hearing about?
-
I'll link to it.
http://brandonw.net/svn/calcstuff/CalcsysX/
-
I've been working on a port of Calcsys, but for the time being it's on the back burner as we wait for the SDK.
-
Somebody compile CalcsysX... lol
Anyways, will they release an SDK?
-
I've been working on a port of Calcsys, but for the time being it's on the back burner as we wait for the SDK.
Is there an official SDK coming out (Flash Debugger?) or do you mean a community one? (Such as the one with Doors CS and WabbitCode)
Also an example of fast pure BASIC graphics using this mode, in case people didn't see it. This takes 5 seconds to generate (although it's not a tilemap, so it's a bit limited, but it only uses drawing commands):
(http://img.removedfromgame.com/imgs/zeldaidea.png)
-
Yes, I meant an official SDK from TI; I've heard rumors that there will be one eventually.
-
My worry, though, is that since they mostly focus on educational stuff, TI might not feel it's urgent to release an SDK nor fix certain display-related bugs in the calculator (such as Pt-On/BackgroundOn), and I wouldn't be surprised if the SDK only came out in 2014 or 2015. I don't think the TI community should hold off software development for 1-2 years just because of that, since it would hurt the community a lot. But again there isn't much we can do when it comes to apps unless somebody comes up quickly with an app signer/compiler (I wonder if there are any plans for a CSE update in WabbitCode?)
-
But again there isn't much we can do when it comes to apps unless somebody comes up quickly with an app signer/compiler
In fact, it quickly turned out that the existing programs for (re-)signing FlashApps work just fine for the 84+CSE.
-
Oh, I absolutely agree, don't wait to start writing great programs! But, assuming the SDK is released fairly soon, it'll be better if we can avoid using unofficial names and terminology, particularly in a program like Calcsys. In any case, there are still some serious issues that I need to deal with before it's usable, and at the moment I have two other TI-related projects (TilEm and TILP) that are a higher priority.
As for app signing, the word is that RabbitSign should work just fine if you can arrange to have an appropriate certificate installed, or if somebody somehow managed to obtain the necessary private keys. ;) With the current version of RabbitSign, you may have to manually specify the program type (since it doesn't recognize the .8ck extension or the 0F product code); I'm planning to release a new version of RabbitSign shortly that fixes those issues.
-
But again there isn't much we can do when it comes to apps unless somebody comes up quickly with an app signer/compiler
In fact, it quickly turned out that the existing programs for (re-)signing FlashApps work just fine for the 84+CSE.
Really? So basically the only difference is that some BCalls and RAM areas moved to different addresses and the LCD stuff is different?
@FloppusMaximus what I guess you could do is wait until June then if by June there's no sign of an imminent SDK release, then start working on apps instead of waiting, in case you end up wasting your time with TI. Just take for example TI-Connect 4.0 Windows, where there were no sign of life for its release for a long while after the calc came out (although it eventually came out with no warning)
-
Really? So basically the only difference is that some BCalls and RAM areas moved to different addresses and the LCD stuff is different?
More or less, yeah. But just like BASIC programs, most assembly programs will need a lot of modifications to make the UI work properly on the larger screen.
@FloppusMaximus what I guess you could do is wait until June then if by June there's no sign of an imminent SDK release, then start working on apps instead of waiting, in case you end up wasting your time with TI. Just take for example TI-Connect 4.0 Windows, where there were no sign of life for its release for a long while after the calc came out (although it eventually came out with no warning)
Yup. I guess we'll see what happens in the next couple of months. The main limiting factor, though, is always my free time. :)