Omnimaga
Calculator Community => Other Calculators => Topic started by: DJ Omnimaga on June 05, 2013, 06:19:45 pm
-
(http://xlib.mtv-music-generator.com/illusiat1csefail.gif)
Game requires over 131736 bytes of archive to run, for 15-60 minutes of gameplay.
You're better off playing the TI-81 remake that was ported to the 83+ instead. It's ridiculously hard, though. :P
-
Uh, lulz?
Well, this proves that porting is going to be REALLY hard.
-
It might not be so hard graphical-wise, unless a game uses pics and you want the game to be as small as possible.
-
Somebody should make a tool for displaying pictures in the B/W format possibly using a customisable pallet and resizing options. Then pictures could still be 768 bytes of data. I know I wrote a quick routine and posted it on Cemetech for just that purpose,so maybe somebody can take it and turn it into a useful program :P
-
Even better: A TI-84+ 2.55MP shell: Basically it would sort-of run old programs in compatibility mode without having to update them.
-
I was considering attempting just such a shell, DJ_O, but I have no time.
-
It would not be too hard on a processor/RAM point of view but to keep the emulator as close as possible to normal speed the screen would have to be refreshed less often. Grayscale emulation would definitively be hard. I would say maybe something like Emu8x for the 83+SE/84+SE but that can also emulate the TI-73 and 83+ instead of just the 82, 82 Stats/83/76.Fr, 85 and 86.
-
Lol, that would be a lot of arc. >.<
Maybe image compression?
-
Yeah I wish they used some sort of compression like on Casio calcs. Casio pics that are really simple only takes the initial 1 KB of RAM plus a few dozens of bytes.
-
It would not be too hard on a processor/RAM point of view but to keep the emulator as close as possible to normal speed the screen would have to be refreshed less often. Grayscale emulation would definitively be hard. I would say maybe something like Emu8x for the 83+SE/84+SE but that can also emulate the TI-73 and 83+ instead of just the 82, 82 Stats/83/76.Fr, 85 and 86.
I could probably count as many as 12 different patterns, systems, and styles of grayscale. Everybody does it differently, mostly because the only games where it is used are worthy of awesome graphics. Grayscale games are written by experienced coders usually, and they are all tailored to the game because it works better different ways for different reason, what with the slow CPU and all. Grayscale emulation would be impossible, programs would have to be rewritten into a standardized way or new ones would need to be written. A detection routine may be possible, finding where the screen is updated constantly... But I suggest using an interrupt that only updates the screen when needed. I have a feeling, however, that a converter will be written so games can be ported to the CSE in a snap.
-
Well, we don't need to worry about constantly refreshing the screen for grayscale, so that might be a boost in speed for grayscale games. LCD updating was always a bottleneck, so that is slightly diminished now that we have a much more responsive LCD to work with (but now we have more pixels to update x.x). Plotting pixels should be a whole lot faster (a few hundred times faster,maybe?) and drawing sprites will also be pretty fast, plus we can add a color aspect to them.
-
I guess that the emulator could feature multiple display modes instead of just Nspire-like. For example, 3x scaling would be the slowest of all, while 2x and 1x would be faster, but harder to see due to small screen. Adding scanlines that don't move would be twice faster, more when extra scanlines are used.
Some examples where you don't necessarily have to update every single pixel:
-
I see one problem to this though : we won't be able to run stuff at 15 MHz. Not a big deal since most ASM games/programs run at 6 MHz, but the 83+SE and the 84+ run TI-BASIC at 15 MHz.
How many cycles does it take to update the whole lcd on the CSE ? And in 160*240 mode ?
-
My routine to draw a 96x64 B/W image using the format that the regular 83/84 calcs have took 308016 t-states to update (about 20FPS at 6MHz).
A routine to just copy a whole image in color is somewhat faster. To make the code small, it would take about 3222600 t-states for a full color image with uncompressed data. Adding a little extra code to make it faster, it can be brought down to 2553600 t-states (about 2.35 FPS).
That being said, the CSE makes it very easy to update only a portion of the screen. so if you have areas of the screen that do not get updated frequently, such as menu items or an HUD, and you cut down how much of the screen is updated to just a 240x240 region, you can draw a 15x15 tilemap of 16x16 sprites at about 3FPS (6MHz) (a single 16x16 sprite, full color, takes about 8512 t-states to draw). You could get 7FPS for a 10x10 tilemap, but then you are only using 160x160 pixels of the screen (half the width, 2/3 the height).
-
Maybe we could just write a routine that emulates the 83+ LCD driver and update the CSE screen ?
-
I see one problem to this though : we won't be able to run stuff at 15 MHz. Not a big deal since most ASM games/programs run at 6 MHz, but the 83+SE and the 84+ run TI-BASIC at 15 MHz.
How many cycles does it take to update the whole lcd on the CSE ? And in 160*240 mode ?
I doubt this would be much an issue, though, because for over a decade, most people ran their games at 6 MHz anyway. Of course this would be problematic for games that are 15 MHz-only, but I think it would be better than nothing in general.
Plus, by displaying fewer pixels (eg scanlines or smaller screen), this gives a speed boost.