Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Wow, I'm glad to see this is still in the works! Keep it up!
It's so beautiful! Reminds me of the fzero test...
Speaking of testing, I've been doing some feasibility testing to see if a racing game would be realistically possible with this.



The frame rate drops when all of the sprites are close together in and at a decent size.

Rough timing of 30fps with minimal object updates (positions only so far) + depth sorting but no collisions or AI as yet so I doubt having > 4 race participants would be probable at this stage. That being said there is still a fair bit that can be optimised so no reason to rule things like this out just yet. If you move slightly away from the objects so the sprites are smaller the frame rate jumps by about 10fps lol.
Framerate-independent movement could fix that pretty easily. It could look somewhat bad at times, but still be very playable. 30 FPS with these graphics is more than sufficient in my opinion, as long as you keep it above 15 or so it should be fine.
I agree, that looks completely playable, even with the potential ~15 fps slowdown. The cluster shown, which is about as dense as I can imagine most races getting, is still able to hit a smooth 30 fps, gives me even more confidence for this project's playability.

If the original Star Fox was playable at roughly 15 fps in places, I'd even say a minimum of 10 fps could still be enjoyable for a game like this, especially with the smooth, clear rendering and art style.
Rather than using the whole screen you could use the bottom or top pixels for other information, such as item and time information. It looks fabulous now! Very Happy
Thanks guys, hoping to get something off the ground.

I had considered frame independent movement however I am a little concerned about a potential performance hit in the calcs, requiring precision mults etc. That being said after chatting with Mateo, Runer, Adriweb etc on IRC I realised that the LCD timing can be configured. I've set it to an effective 25fps (50fps in reality), which can be seen in the screenshot above.

Note that I haven't yet attempted to properly optimise the drawing routines. The frame rate jumps over 10fps when the sprites aren't as large or clumped together lol.

A great point Mateo, I certainly plan on not updating the top of the screen unless necessary. I might shrink the scrolling background from 16 pixels to 8 pixels and not solid fill the rest each frame for some performance benefit.

EDIT - I added some stuff to make simple AI possible, now you can race against an ai!

It's very crude and has bugs that need fixing, but it's something:


EDIT 2 - I fixed the waypoint handling so now the ai's will travel the whole track in all directions ... forever lol. Also tested mass ai racers!


This is from the ai's point of view - basically hits a waypoint then magically points to the new one (this will be changed to actual steering most likely) - though these are just test points and not what would be in a real level (caution may cause motion sickness):
Looks good, glad to see you got the AI somewhat working. Is this really running at a consistent 50+ FPS?
Very Nice Implementation
Thanks Smile - The framerate jumps about due to what's on screen - multiple large scaled sprites slow it down considerably - but it stays above 30 in my tests thus far with enough action going on.

I have LCD updates locked at 30fps (I might change this to 25fps), the number in the corner is the real rate at which the engine is working at however.
I love how well this project is planning out!!

I ma excited to see how far it goes:3
Wow, this is really progressing; It already looks incredibly polished, and the performance is quite promising. I can't wait for a playable demo!
I didn't miss any existing download links, did I?
Wow. Currently, I am attempting to program breakout, and you're here programming Mario Kart. Technology can do amazing things. Mario Kart on a calculator?????!!!!!
I've been working a little on this project - rewriting some of the engine due to data space worries and working on some easy performance gains. I've also converted over some more sprites so now there are different characters!

Wow, this is coming along great! Looks even better than the original SNES version. Your ability to use decimal arithmetic/trig makes the maps look way smoother than the SNES ever could. I can't wait for you to release a playable demo.
This looks way, way faster than I remember it being, but perhaps I have the CSE version in my brain. I just hope that no one kicks up a fuss about those Oiram and Igiul sprites. Wink What were the data space worries?
What a great acomplishment!!!

Almost as fast as the F-Zero , for comparasion Razz The framerate is very stable .
I guess it's always ran fairly well on the CE - though I have tweaked the code a fair bit thus far. That being said a decent chunk of the code is hacked and slashed from older routines - so a fair bit more work is needed o tidy things up. HOWEVER that is the trap I usually fall into which causes projects to stagnate - So I'm focusing on getting some actual content into this to keep it moving. I can worry about tidying things up later.

The engine runs in 4bpp mode with a 'simulated' half res 160x120. In 4bpp mode 1 byte = 2 pixels so for speed reasons I was storing sprite data pre-doubled. This made things faster but each character sprite is 24x24 x 7 frames per character which turns out to be ~4KB each. 8 characters was going to require a 32KB buffer, not to mention all of the other sprites needed like items, pipes, coins etc etc. So I decided to roll back all of my drawing routines to draw from 4bpp data instead, basically halving my memory requirements for sprites. Obviously a performance hit sine you have to read by nibble though I came up with a good enough way to do it without sacrificing too much speed + I relocated some inner loops to SHA256 RAM and the net result was an [marginal] overall speed increase!

Regarding the sprites, well Oiram didn't seem to attract too much attention for basically ripping sprites ... I've at least done *some* rework Smile.

On the SNES there isn't a Donkey Kong, rather it's Donkey Kong Jr ... I spent a little time trying to make a DK-ish sprite and am happy with my initial effort:



Looks close enough so far, especially considering the colour restrictions I have ...

I currently have 7 characters, hoping for 12 overall.
This is fantastic, holy heck!

Out of curiosity, are you able to take advantage of RLD and RRD for nibble extraction?
Indeed some thought had gone into those instructions - as discussed last night!

Here is another screenshot showing all 8 characters from the driver's perspective:

  
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
Page 4 of 5
» All times are GMT - 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