So as I was working on some LCD update things today, I got a little bored and took a little look at the ion fastcopy routine. As most programs for monochrome calcs use some type of LCD update with a buffer, rather than simply writing directly to the LCD ports to reduce flicker, I was wondering what would happen if I just drew this buffer pixel by pixel to the LCD on the TI84+CSE. And the results turned out pretty well; however most text bcalls don't work because they use a different sized font. But they can easily be rewritten. (Also I think I messed up something I wasn't supposed to in the main file, so some enemies seem to run a tad slower. That's easy to find though.

I'm thinking that if I also implemented VRAM swapping along with drawing each line twice, I could double the size. Plus colors are customizable, by that I mean the screen can only be one color. Razz

The cool thing about this is is that mostly all code can be kept the same, all that needs to be fixed is instead of including ion, I just wrote a separate include file that compiles them using my update routine. Now, enough talk. Here's a test of the Mario game 1.2 by Sam Herald on the CSE.

Fun hacking project! Can't wait to see how your further efforts turn out.
Wow looks awesome! I do think it could benefit from pixel doubling etc as thats bound to be very tiny - in 160mode it could work quite nicely I imagine Smile.
Mario on the CSE? Cool! Very Happy
In all seriousness though, is this going to happen? Mateo, I know you are wrapping up Portal, are you looking for a new project?
Also, does this mean that other games like pheonix or something could be ported this way?
Unicorn wrote:
Mario on the CSE? Cool! Very Happy
In all seriousness though, is this going to happen? Mateo, I know you are wrapping up Portal, are you looking for a new project?
Also, does this mean that other games like pheonix or something could be ported this way?

Indeed it does. This makes porting games nicely, but in all seriousness, making a color version would be a major undertaking, I just used the monochrome Mario because I was already working with it. Smile But this means that ports could be feasible, but color support for monochrome games is probably impossible. Smile
Well you could do 1 colour or foreground/background etc ... ?

Or there is the TI-Boy CSE method which could work for grayscale games (specify colours for each shade instead).
Awesome! I agree, if you went to 160 mode and doubled the number of vertical lines, it would look great in 2x res Smile
So this makes porting games to color easier, but not by to much?
Would a black an white port be relativly easy?
Unicorn wrote:
So this makes porting games to color easier, but not by to much?
Would a black an white port be relativly easy?

Yeah, that is relatively easy for most games. Also adding in a customization for background and foreground would work too. But making it color usually requires a full rewrite. Razz
You could make a game like Pheonix look pretty convincing, isn't it only three colors?
JamesV wrote:
Awesome! I agree, if you went to 160 mode and doubled the number of vertical lines, it would look great in 2x res Smile

Oh, I just tried that out and it looks quite nice. I unraveled some loops to speed things up too. The only problem is that updating is still a little slow... I need to figure some things out to make it faster. Razz

EDIT: tr1p1ea++ times 1000 for this program: http://www.ticalc.org/archives/files/fileinfo/348/34894.html This makes adding text and stuff that much easier! Very Happy Very Happy



Unicorn wrote:
You could make a game like Pheonix look pretty convincing, isn't it only three colors?

Yeah, I could, but the way this works I can only have two colors... Unless... Hmm... Very Happy
Looking nice, how much z80 ASM do you need to get the program runming on the screen like that?
Unicorn wrote:
Looking nice, how much z80 ASM do you need to get the program runming on the screen like that?

Honestly, it wan't too hard. As long as you have the source, it is pretty nice to make it work. Of course, you can't use hardware vertical scrolling, but writing a software routine to do that isn't bad. Smile

This took me about ten minutes to change, but quite a bit longer to write the code to make it do it right. Smile


Here's a couple examples that I just randomly selected off of the webs:

3D maze:


Rubiks Cube:


EDIT: So here' the idea that I was thinking about, but not sure if it is feasible at all right now: As tr1p1ea was saying, I could have different colors for different buffers, but that would require updating multiple times per frame, unless there is someway to avoid that... Confused
Very impressive Mateo! I guess it stands to reason that I could port AB5 to the TI-84+CSE, albeit in monochrome and not running as fast as on the non-CSE calcs. But nevertheless it would still be interesting to try. I might give it a go sometime!

MateoConLechuga wrote:
EDIT: So here' the idea that I was thinking about, but not sure if it is feasible at all right now: As tr1p1ea was saying, I could have different colors for different buffers, but that would require updating multiple times per frame, unless there is someway to avoid that...
You could possibly do something like two 768 byte buffers to simulate grayscale, or 4-colour graphics. For each pixel write to VRAM you'd need to check the respective bit/byte of each buffer to work out what colour is required to be displayed.
Oh, that's a good idea! I might only be able to get 3 colors, because the background needs to have a transparent layer... Unless I'm mistaken? Anyhow, Alien Breed should work fine, just need a hardware to software vertical scroll. I actually tried to build it with both spasm and brass, but for some reason couldn't get it to compile... Razz spasm just decided to quit randomly on Pass 1... It's probably my fault. Razz

Anywho, I'll give that a try and see what materializes. Smile

Hmm... Mobiletunes3 port? Razz



Here's some software scrolling tests:


Hmm... I'm thinking that there could be two options, one to activate small screen mode, which runs a little faster, and then half-res....
a thats cool work there bud! Nice to see someone using some tricks to make some games work like magic on the CSE!
Is it too much work to write versions of the sprite routines and text routines that draw directly to the LCD, and not bother going through a gbuf surrogate at all? That would allow the sprite-draw calls to gradually be replaced with color sprite data and calls to the DCSE sprite routines, if the programmer so desired. I continue to want to help work on this project myself, but you're making huge strides on your own. Good work!
KermMartian wrote:
Is it too much work to write versions of the sprite routines and text routines that draw directly to the LCD, and not bother going through a gbuf surrogate at all? That would allow the sprite-draw calls to gradually be replaced with color sprite data and calls to the DCSE sprite routines, if the programmer so desired. I continue to want to help work on this project myself, but you're making huge strides on your own. Good work!

Actually, the code for this is just an adapted form of one of the sprite routines I had for 2 color sprites.... But there's no masking or clipping or other things. DCSE sprites are already supported; you can draw to the screen however you like. Smile It just prints out the data at plotsscreen when updating.

There still needs to be a replacement for the vputs and vputsn bcalls; tr1p1ea's font routine works well, but it doesn't mask out the current pixels it overlays on the characters... Also, I'm not sure, but setting the text inverse flag probably doesn't work right. Razz
Mateo, if you don't mind could you please teach me how to do this?
Unicorn wrote:
Mateo, if you don't mind could you please teach me how to do this?
You should learn assembly first and get some significant experience with the language before attempting something like what Mateo is doing here (otherwise you'll get quite frustrated indeed). We generally recommend using TI-83 Plus Assembly in 28 Days with the Brass assembler, usually in the form of the Doors CS or Doors CSE SDK.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page 1, 2, 3, 4, 5  Next
» View previous topic :: View next topic  
Page 1 of 5
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement