whats the trick to drawing fast screens?

Started by WacKEDmaN, 01:08, 28 October 22

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

WacKEDmaN

im looking for some info on drawing screen (or part of) fast

id like to make an outrun style racing game...
ive played around with some C code (with cpctelera) to draw the screen, but its taking way too long to just draw the track (worse than a slide show!..no sprites yet)  i even tried porting it to basic, but that was hella slow!
this is what im attempting to port across, (just the road/ground surface itself atm)
https://github.com/OneLoneCoder/Javidx9/blob/master/ConsoleGameEngine/SmallerProjects/OneLoneCoder_RetroArcadeRacer.cpp

im wondering if someone can let me in on the secret to drawing it fast! (atleast the bottom half of the screen!) or direct me to a topic on the forums here that discusses it...(im not sure what to search for!)

i know ASM would be faster/more optimised, but i feel more proficient coding in C...

thanks

andycadley

On modern computers you can do all that nice stuff with floating point numbers, multiplications and trigonometry to calculate the exact curvature of the road and it will whizz along.

On an 8-bit CPU, no chance. You have to fake everything. You need to use Integer math to have any hope of speed (or fixed point which is mostly the same) and you need to cut every corner possible, often sacrificing accuracy for speed.

WacKEDmaN

yes! thats probably a good start! thanks!

after giving a bit more thought... i guess i need to directly write to the vid memory region for the best speed....
im going to have to look into how to do that via C

Fran123

Hello

To save clock cycles you must use assemble code. I suposse you use functions, and each call to C function is translated to assembly code with several push and pop instructions.

McArti0

CPC 6128, Whole 6128 and Only 6128, with ........
TYPICAL :) TV Funai 22FL532/10 with VGA-RGB-in.

andycadley

Yes, plotting via the firmware (which is Mode independent) or BASIC, is going to be very slow.

But it's also missing the biggest point. You don't ever want to be plotting individual pixels at all! You'd be drawing horizontal road lines and so writing to video memory in a linear fashion a byte at a time.

And that still overlooks where the real performance gains are: in actually calculating what the road needs to look like. A naïve implementation like the OP links to will certainly do it (and in fact do it more correctly than most old school racing games in terms of perspective) but it's far too slow an algorithm for practical use on old computers.

There used to be a really good article on how these old race games did the maths for the road, but I can't remember where or find the link right now. In essence it's about thinking of drawing the road as a series of pre-sized strips and then doing as little maths as possible to determine which strip goes where at any given point in time.

WacKEDmaN

#6
awesome thanks peepz...

@andycadley yup thats what i came up with after some more thought!... predefined sections in an array with colour flipping for sense of movement.. 

..i also remembered to check out the actual wiki..  ::)

ervin

I'm very interested to see where this project goes.

This article is something I've read in the past, but didn't understand too much of it.
I need to have another try some day...
http://www.extentofthejam.com/pseudo/

andycadley

Quote from: ervin on 15:13, 28 October 22I'm very interested to see where this project goes.

This article is something I've read in the past, but didn't understand too much of it.
I need to have another try some day...
http://www.extentofthejam.com/pseudo/

That was exactly the link I was thinking of but couldn't find.  ;D

ervin

Quote from: WacKEDmaN on 14:35, 28 October 22awesome thanks peepz...

@andycadley yup thats what i came up with after some more thought!... predefined sections in an array with colour flipping for sense of movement..

..i also remembered to check out the actual wiki..  ::)

As you get into this further, there will be times where you shouldn't plot individual masked pixels. You'll be wanting to fill entire bytes with no masking, wherever possible. Even in C this will cause a significant speed-up.

WacKEDmaN

Quote from: andycadley on 15:59, 28 October 22
Quote from: ervin on 15:13, 28 October 22I'm very interested to see where this project goes.

This article is something I've read in the past, but didn't understand too much of it.
I need to have another try some day...
http://www.extentofthejam.com/pseudo/

That was exactly the link I was thinking of but couldn't find.  ;D
ahh yeah ive seen that article...thanks for the reminder..

dont get too excited to see too much... i still need to get around to doing anything about it!... just trying to gather as much info i can before jumping in...

WacKEDmaN

im also starting to wonder if i can fake corners with some CRTC rapture, that way i only need to draw a straight road once!...
..hmm but that might bend sprites coming towards tho..

Optimus

#12
Quote from: WacKEDmaN on 01:08, 28 October 22im looking for some info on drawing screen (or part of) fast

id like to make an outrun style racing game...
ive played around with some C code (with cpctelera) to draw the screen, but its taking way too long to just draw the track (worse than a slide show!..no sprites yet)  i even tried porting it to basic, but that was hella slow!
this is what im attempting to port across, (just the road/ground surface itself atm)
https://github.com/OneLoneCoder/Javidx9/blob/master/ConsoleGameEngine/SmallerProjects/OneLoneCoder_RetroArcadeRacer.cpp

Looking a bit at the code, I'd say, one does not simply use C++ code as it is on 8bit expecting to run fast. First of all, I am not even sure about the modern C++ stuff like vectors and pairs, I have no idea whether this will be much slower than pure C. And there might be articles that try to prove the you can write modern C++ in 8bits and not think about it, but the problem is more people assume all these things are for free, but you don't know. To make sure I am not bitten by the compiler, if I'll write it's going to be pure C. If I don't write the entire thing in assembly of course.

Maybe some things are ok if they happen in the initialization, but you have to be conscious of what's going on especially in the main loop. Floats for example. These can be extremely slow even if you use them in small quantities. In that provided code you have a full per pixel loop, adding and multiplying floats every pixel. Btw,. the easiest optimization (which will still not save you, but it's there),. fPerspective is based on y coordinate only. You can move it out of the X loop, so that it happens once every line. Then other floats are based on fPerspective, you can move them out too. Almost everything can move out. The code is written like a tutorial (it's not yours I guess but from the guy in the video?). Some codes work for modern machines, not for straight porting. Even if you wrote everything in assembly it would still be slideshow. And even if you wrote everything in assembly and avoiding floats, it would still be very very slow.

I would try to understand the algorithm, rewrite it using purely fixed point integers and see how it goes (still extremely slow), then see if it's horizontal scanlines with single filled color, if I could only render the few pixels that change, which might need some redesign of the algorithm. Then maybe things can be rewritten in assembly. And I'd say, making an outrun game with pure C is a daunting task. C could be used minimally, like for moving few sprites, and then the main rendering should be assembly. Unless you move few dots that you can render with C. I am trying stuff in SDCC, it's not bad, I could write the whole game logic for few sprite movements and collision in pure C, it might be good for that if you don't want to avoid assembly. Also initialiations and all that nitty gritty, but the rendering especially for big areas of the screen has to be 100% assembly and still it wouldn't be as fast with some hardware tricks.

Optimus

To add a bit more microptimizations to the original code (although it might be pointless),. I think at least in SDCC int defaults to 16bit, so I have typedefs int8,uint8 to char and unsigned char, to make sure everything that is inside the 0-255 or -128 to 127 range are defined as int8/uint8. Also, in the inner loops and everywhere there is a function ScreenWidth() or ScreenHeight(), that's pretty bad as every loop it will call the function to retrieve and compare, instead you could go outside all main loops at top and write const int screenWidth = ScreenWidth() if you want,. and use the consts for the loops. Even better if they are macro defines, if you know resolution will be fixed.

Generally, there is a different way to think around optimizing for 8bits, than modern PC code. There might be more stuff in the code that can be improved, but it will go from extreme slideshow to lesser slideshow.

luckpro

Quote from: WacKEDmaN on 01:08, 28 October 22im looking for some info on drawing screen (or part of) fast

id like to make an outrun style racing game...
ive played around with some C code (with cpctelera) to draw the screen, but its taking way too long to just draw the track (worse than a slide show!..no sprites yet)  i even tried porting it to basic, but that was hella slow!
this is what im attempting to port across, (just the road/ground surface itself atm)
https://github.com/OneLoneCoder/Javidx9/blob/master/ConsoleGameEngine/SmallerProjects/OneLoneCoder_RetroArcadeRacer.cpp

im wondering if someone can let me in on the secret to drawing it fast! (atleast the bottom half of the screen!) or direct me to a topic on the forums here that discusses it...(im not sure what to search for!)

i know ASM would be faster/more optimised, but i feel more proficient coding in C...

thanks

As a general rule in cpc to draw fast:
1º use asm, the C compiler is very optimized but in asm you can optimize more.
2º check the code that it draws on the screen, it has to do as little as possible (try not to draw areas that don't change, try to use ink changes to emulate movement, in general, use all the tricks you know).
3º if you can, use the stack to draw, it is usually the fastest way to do it
4º avoid using float numbers, whenever you can u8 1 byte. 

for racing games:
5º in some cases color changes can be used using the raster to simulate the movement of the road (perhaps not your case).

And above all think that in cpc it is not easy, look at other racing games how they do it.

roudoudou

Quote from: WacKEDmaN on 01:08, 28 October 22im looking for some info on drawing screen (or part of) fast

id like to make an outrun style racing game...
ive played around with some C code (with cpctelera) to draw the screen, but its taking way too long to just draw the track (worse than a slide show!..no sprites yet)  i even tried porting it to basic, but that was hella slow!
this is what im attempting to port across, (just the road/ground surface itself atm)
https://github.com/OneLoneCoder/Javidx9/blob/master/ConsoleGameEngine/SmallerProjects/OneLoneCoder_RetroArcadeRacer.cpp

im wondering if someone can let me in on the secret to drawing it fast! (atleast the bottom half of the screen!) or direct me to a topic on the forums here that discusses it...(im not sure what to search for!)

i know ASM would be faster/more optimised, but i feel more proficient coding in C...

thanks

if you dont want to use assembly, i think the only way to go will be a mix of precomputed turns and color cycling (you could have better results with 2 screens for each angle + color cycling, then you avoid the obvious "oh, this is color cycling :D"

see supercycle using this technic, it's obvious
https://www.youtube.com/watch?v=REvRTSDmx8w

but if you have a frame for borders in position and another for borders in half-position (am i clear?)...

then you have only to move vehicles and a little the borders when you turn (you can use delta or partial frames)


use RASM, the best assembler ever made :p

I will survive

WacKEDmaN

thanks for all the great tips guys.....

...now ive just gotta put it all into practice!...  :P :laugh:

Powered by SMFPacks Menu Editor Mod