How do you rotate sprites at 3:59? is it made using math (sin, cos), like a rotozoom? I'm interested in programming little demos for the megadrive genesis, is it fast enough to rotate vectors or sprites using "c" code ? It really seems a powerfull device. Thanks a lot
Yeah, I wouldn't trust using C on any of the 16 bit consoles. Though the penalty isn't quite as harsh on a 68000 based system as it would be on a 65c816 one. (65c816 is a bit more forgiving, but the 6502 architecture is very poorly suited to stack frame based programming languages - which... Is most of them. - at least, the popular ones) Other than that, rotation and scaling is a lot of multiplication and division, but indeed you need sin and cos as well. On the Mega Drive/Genesis you'd have to calculate it all on the CPU then transfer it to video memory for display. On SNES of course there's mode 7, which in modern terms is effectively a fixed function texture mapping system (that maps to 2d screen space coordinates) While they take much less calculation than they would if done on the CPU, mode 7 requires calculating the scaling, rotation and translation parameters on the CPU, and for that really popular perspective view in addition requires re-calculating some of the parameters per scanline. (though HDMA helps you here in that you can calculate, say a fixed perspective scaling effect once, store it in memory, then simply transfer this static list of parameters to the Mode 7 registers using HDMA.) In either case, you do need cos and sin, but those systems don't have the hardware for it, and software calculation would cripple them. As with most things in computing, you can trade memory (or in this case, ROM space) for CPU time by creating a lookup table. Since you don't need a huge amount of precision, a 256 or 360 entry table would suffice. (depends on your preferences really.) A 360 entry cosine table containing 16 bit fixed point values (which is what you'd need on the SNES for mode 7. But would make sense for the Mega Drive too) is 720 bytes. This can be in ROM, and while not trivial, it's still small enough that a 1 to 2 megabyte game ROM can certainly afford a few tables like that. About 1.5 kilobytes will get you cos and sin tables more than good enough for rotation and scaling effects. A few more tables will get you some other values that help reduce the CPU load further. But anyway, if you're wondering how some complex maths function is done in realtime on old hardware, 9 times out of 10 a lookup table being involved would be a good bet. Stay away from C or really any high level language though if you can. The 16 bit consoles simply don't have the power for it. (the snes especially has a CPU architecture that clashes with how most compilers are written. there IS a C compiler for it, but to give you some idea of how bad it is, the compiled code is about 1/10 as fast as even moderately well written assembly code. And when your CPU runs at under 4 mhz you do NOT have the luxury of throwing out 90% of your performance. The situation with mega drive compilers isn't quite THAT bad, but it's still not good. If you wanna work with 16 bit consoles, you really should learn assembly.)
Awesome demo, as well as Overdrive 2 which I ad the chance to see live at Revision. Keep up the good work :)
The loading bar!!
This is fantastic. And especially - the music. Congratz, all.
Irgendwann hab ich auch mal die Zeit nicht die 68k sondern die 65816 zu quälen. :D
Yeah, bring back my old times!
Beautiful, awesome! + Respect...
Impressive
Great demo, i prefer the music in this one rather than the one in OD2.
How do you rotate sprites at 3:59? is it made using math (sin, cos), like a rotozoom? I'm interested in programming little demos for the megadrive genesis, is it fast enough to rotate vectors or sprites using "c" code ?
It really seems a powerfull device.
Thanks a lot
C is very slow, but it should work. Assembly definiteyl will work out best for you :)
And don't forget that you can use data tables to speed up things with high level languages. A very good technique too for CPU's without a FPU unit.
I doubt C will be fast enough. They must have used the copros and / or on the fly generated code.
I'd imagine mostly because of the shitty C compilers that you have for the 68000 that haven't been updated in a quarter century
Yeah, I wouldn't trust using C on any of the 16 bit consoles. Though the penalty isn't quite as harsh on a 68000 based system as it would be on a 65c816 one. (65c816 is a bit more forgiving, but the 6502 architecture is very poorly suited to stack frame based programming languages - which... Is most of them. - at least, the popular ones)
Other than that, rotation and scaling is a lot of multiplication and division, but indeed you need sin and cos as well.
On the Mega Drive/Genesis you'd have to calculate it all on the CPU then transfer it to video memory for display.
On SNES of course there's mode 7, which in modern terms is effectively a fixed function texture mapping system (that maps to 2d screen space coordinates)
While they take much less calculation than they would if done on the CPU, mode 7 requires calculating the scaling, rotation and translation parameters on the CPU, and for that really popular perspective view in addition requires re-calculating some of the parameters per scanline. (though HDMA helps you here in that you can calculate, say a fixed perspective scaling effect once, store it in memory, then simply transfer this static list of parameters to the Mode 7 registers using HDMA.)
In either case, you do need cos and sin, but those systems don't have the hardware for it, and software calculation would cripple them.
As with most things in computing, you can trade memory (or in this case, ROM space) for CPU time by creating a lookup table.
Since you don't need a huge amount of precision, a 256 or 360 entry table would suffice. (depends on your preferences really.)
A 360 entry cosine table containing 16 bit fixed point values (which is what you'd need on the SNES for mode 7. But would make sense for the Mega Drive too) is 720 bytes.
This can be in ROM, and while not trivial, it's still small enough that a 1 to 2 megabyte game ROM can certainly afford a few tables like that.
About 1.5 kilobytes will get you cos and sin tables more than good enough for rotation and scaling effects.
A few more tables will get you some other values that help reduce the CPU load further.
But anyway, if you're wondering how some complex maths function is done in realtime on old hardware, 9 times out of 10 a lookup table being involved would be a good bet.
Stay away from C or really any high level language though if you can. The 16 bit consoles simply don't have the power for it.
(the snes especially has a CPU architecture that clashes with how most compilers are written. there IS a C compiler for it, but to give you some idea of how bad it is, the compiled code is about 1/10 as fast as even moderately well written assembly code. And when your CPU runs at under 4 mhz you do NOT have the luxury of throwing out 90% of your performance.
The situation with mega drive compilers isn't quite THAT bad, but it's still not good.
If you wanna work with 16 bit consoles, you really should learn assembly.)
Noice
Titan pwnage! 3:D
*ШЕ-девар)*
Rulez!
Anyone to tell me how you he's able to dev such demo for megadrive ? I guess he used assembly and play it from emulator ?
Yes, we use assembly. But it's played from real console.
Oerg866 Make a game already.