Jump to content
IGNORED

Atari v Commodore


stevelanc

Recommended Posts

 

Dang, I really don't have time to code this up this week.. :(

 

That's the problem with places like this thread or talking to other coders, constantly new things for us to be interested in doing and never enough time for them all. I'd love to have more of a play with code for it as well but every time I think about it I think of different possibilities and I've already got an artist waiting to murder me for not working fast enough coding things to drop his graphics into :(

 

 

 

Pete

Edited by PeteD
Link to comment
Share on other sites

ROFL

 

That does it, I'm applying to the Bill and Melinda Gates Foundation for a grant to help those with terminal retro-geekitis.

 

 

Pete

While you're doing that, I'll go buy a lotto ticket. :)

 

I think I have another way to generate a floor that greatly reduces the amount of math... Argh!!!

Link to comment
Share on other sites

Jason, hurry up with yer forum! hehe All this is getting terribly off topic reaaaly. Talking about mode7 and stuff, we need somewhere else to go and waffle about it :)

 

Oy, you already know i'm ill! (Okay, it'll be a close to unpatched phpBB3 but give me some time...)

Link to comment
Share on other sites

Jason, hurry up with yer forum! hehe All this is getting terribly off topic reaaaly. Talking about mode7 and stuff, we need somewhere else to go and waffle about it :)

 

Oy, you already know i'm ill! (Okay, it'll be a close to unpatched phpBB3 but give me some time...)

 

Ill? tsk, I hear it's girly sniffles ;)

 

 

Pete

Link to comment
Share on other sites

Jason, hurry up with yer forum! hehe All this is getting terribly off topic reaaaly. Talking about mode7 and stuff, we need somewhere else to go and waffle about it :)

 

Oy, you already know i'm ill! (Okay, it'll be a close to unpatched phpBB3 but give me some time...)

 

Ill? tsk, I hear it's girly sniffles ;)

 

Yeah yeah, whatever... [sniffle] Okay, forum's up so go talk at each other for a bit whilst i recover or something! (i bloody know i'm going to regret this entire idea, but hey... if i didn't do everything i regretted i'd not have the mickey taken out of me when i'm ill!)

Edited by TMR
Link to comment
Share on other sites

Yeah yeah, whatever... [sniffle] Okay, forum's up so go talk at each other for a bit whilst i recover or something! (i bloody know i'm going to regret this entire idea, but hey... if i didn't do everything i regretted i'd not have the mickey taken out of me when i'm ill!)

 

Cool, let gentlemanly conduct begin :)

Link to comment
Share on other sites

I'd like to see a Commodore 64 version of Star Raiders. Maybe one of you super-coders can do it, and jazz it up to surpass the A8 original with more color, etc. Could the C64 do a "color" version of Star Raiders?

 

i have to say that this one appeals to me :)

 

yes you could do Star Raiders in colour. the only potential stumbling block i can see is the use of "particle" graphics for explosions, which drags down the 1.8mhz atari chip so is certain to have a similar impact on the c64. however i would have thought that the use of c64 sprites to generate the rest of the graphics would compensate somewhat.

 

however the 64 already has a Star raiders clone called Sentinel

My link

 

it doesnt however have decent version of Star Raiders 2/last starfighter. Activision naused that one up completely.

 

anyway if Star Raiders floats your boat have a look at PSI 5 Trading co

My link

 

Steve

Link to comment
Share on other sites

 

yes you could do Star Raiders in colour. the only potential stumbling block i can see is the use of "particle" graphics for explosions, which drags down the 1.8mhz atari chip so is certain to have a similar impact on the c64. however i would have thought that the use of c64 sprites to generate the rest of the graphics would compensate somewhat.

 

 

There was a hack floating around this forum a year or two ago that cut the number of particles down to avoid the slowdown. I remember reading the posts and playing with the bin but I had no luck searching out. Perhaps someone with a better memory....

 

Star Raiders is also interesting in that it was the killer app for the 400/800 launch. That game running on store displays sold some A8s. It is also notable for packing a fair amount of depth into an 8K cart.

Link to comment
Share on other sites

I'd like to see a Commodore 64 version of Star Raiders. Maybe one of you super-coders can do it, and jazz it up to surpass the A8 original with more color, etc. Could the C64 do a "color" version of Star Raiders?

 

It would have to fit in 8k - the 8bit can do a color version of Star Raiders!

Link to comment
Share on other sites

...I think I have another way to generate a floor that greatly reduces the amount of math... Argh!!!

Early morning is good for getting new ideas :)

What about this:

Yoomp routine is simple precalculated kinda chunky to combined bits into bytes routine. LDA ORA ORA ORA STA in core. With indexes it can draw stuff from texture moved in one axis without additional cost. So, what if you have much more movement in one direction than rotations ? If you limit rotation steps to only 1 in N movements of "forward" movement, you can prepare texture buffer in that direction, every move forward you have to add only one line from floormap to texture, and while doing those N moves you build another texture buffer in different angle ? And after N steps you change buffer and continue in that direction.

Rendering routine takes alot of memory, but some ratio could be found... Yoomp plots over 6000 pixels in 2 frames (25fps), but uses mirror effect so rendering routine is only half of that size... and that half is around 12k :(

 

15 bytes are needed for 4 pixels, so something like quarter of narrow mode screen , 128x24=3072 pixels, would take 11.5 Kb. Double that and you get 23k for rendering code only... With all extra drawing second buffer you could maybe get away with maybe 3 or 4 frames total... That would be 16 or 12 fps...

 

Don't know if that is of any use, but I had to write it down :)

 

p.s. You could move this conversation into programming sub forum ....

Link to comment
Share on other sites

Yeah, it needs some faster way of drawing the closer repeated areas.

 

You're right about starting at the back, that's how it's usually done, each scanline gets a new calculation for that lines X and Y increments in the "map". Using tiles of course would mean also having the tile "number" held in a map somewhere but I was talking more simple Ballblazer on/off type thing and have it 2 colour checkerboard. You're going to really need at least an 8:8 calculation for everything else it's going to be a mess I should think. Each pixel (for a fully mapping one) then needs to add that to the source pointer, do a read, at least a write, a wrap check when the offset is added, etc. It really is kind of a nightmare cpu wise.

 

I think the simplest way is do a 3d grid rotation, doesn't need too many points so not "that" many matrix muls (in fact due to it being a grid there are probably lots of cheats), and then a quad fill routine (or a linedraw and Y bucket). Certainly faster than reading source data but means you're stuck back with the checkerboard again.

 

Yep. You have to see what operations can be eliminated by look-ups or pre-mangled data and what inaccuracies you can accept for speed. I had also thought of a tile-plotter that could draw at various rotations and sizes and filling in the floor that way. Tiles further away would not need the accuracy of close up tiles.

 

Dang, I really don't have time to code this up this week.. icon_sad.gif

 

Have you ever taken a closer look at Rescue on Fractalus? Behind the scene?

Or just watch the videos on youtube again.

 

C64 is already doing all that stuff...

-No VBI fixed graphics

-Drawing closer ranges more often than distant ones.... and so on....

 

.... while the Atari is simply drawing frame per frame , beeing allmost 3x as fast ?

 

What will we see on the A8 after using all those speedup tricks?

 

I guess, Space Harrier is even using non of them. The only "speedup trick" is the lookup table for the "sprite faces"... but it draws every frame fully, being that fast already.

Link to comment
Share on other sites

I played around with the ideas of mode7 years ago when having my snes and doing all the chunky stuff on A8...

 

of course you can precalculate the texture mapper and you can make it little bit more flexible... but to have 50 fps it is impossible to have a flexible texture mapper where the angle is flexible... as LDA ORA STA is the fastest possible way... and remember that in mode7 we are not using a 80x60 display but a more flexible one with scanline resolution so first of all we would need to calculate how much plotted pixels we are talking about?

 

if we have this number we can caculate how much ram would the precalculated rendering routine would need. than we see how much cycles are left to implement a more flexible one than the mentioned fixed one. and we know how long these routine would be and then we can think about reusing the mapper for more than 1 angle for the turns...

 

and... if we are talking about using others than mode9/10 or 11... remember that code size doubles plus ram usage for the textures is 4x... (LDA ORA ORA ORA STA).

 

just my 2 cents.

Link to comment
Share on other sites

Yeah, it needs some faster way of drawing the closer repeated areas.

 

You're right about starting at the back, that's how it's usually done, each scanline gets a new calculation for that lines X and Y increments in the "map". Using tiles of course would mean also having the tile "number" held in a map somewhere but I was talking more simple Ballblazer on/off type thing and have it 2 colour checkerboard. You're going to really need at least an 8:8 calculation for everything else it's going to be a mess I should think. Each pixel (for a fully mapping one) then needs to add that to the source pointer, do a read, at least a write, a wrap check when the offset is added, etc. It really is kind of a nightmare cpu wise.

 

I think the simplest way is do a 3d grid rotation, doesn't need too many points so not "that" many matrix muls (in fact due to it being a grid there are probably lots of cheats), and then a quad fill routine (or a linedraw and Y bucket). Certainly faster than reading source data but means you're stuck back with the checkerboard again.

 

Yep. You have to see what operations can be eliminated by look-ups or pre-mangled data and what inaccuracies you can accept for speed. I had also thought of a tile-plotter that could draw at various rotations and sizes and filling in the floor that way. Tiles further away would not need the accuracy of close up tiles.

 

Dang, I really don't have time to code this up this week.. icon_sad.gif

 

Have you ever taken a closer look at Rescue on Fractalus? Behind the scene?

Or just watch the videos on youtube again.

 

C64 is already doing all that stuff...

-No VBI fixed graphics

-Drawing closer ranges more often than distant ones.... and so on....

 

.... while the Atari is simply drawing frame per frame , beeing allmost 3x as fast ?

 

What will we see on the A8 after using all those speedup tricks?

 

I guess, Space Harrier is even using non of them. The only "speedup trick" is the lookup table for the "sprite faces"... but it draws every frame fully, being that fast already.

 

Sheddy will love to answer that... ;) and SH does how many turns left/right?

Link to comment
Share on other sites

i have to say that this one appeals to me :)

 

yes you could do Star Raiders in colour. the only potential stumbling block i can see is the use of "particle" graphics for explosions, which drags down the 1.8mhz atari chip so is certain to have a similar impact on the c64. however i would have thought that the use of c64 sprites to generate the rest of the graphics would compensate somewhat.

 

Do you mean the particle effects for explosions ? Like

Is the the level of particles we're talking about, or is there something larger you're referring to ?

 

It doesn't look at all difficult for a 64 to do that, and the hardware sprites will more than make up for any CPU differences, and the fact (I think) it appears to be running in half-res mode..

 

But there was already Star Raiders II on the 64.. Don't know how close or true it is to the original SRII..

Looks a bit kack'ola if you ask me ;)

star_raiders_ii_02.gif

Link to comment
Share on other sites

I played around with the ideas of mode7 years ago when having my snes and doing all the chunky stuff on A8...

 

of course you can precalculate the texture mapper and you can make it little bit more flexible... but to have 50 fps it is impossible to have a flexible texture mapper where the angle is flexible... as LDA ORA STA is the fastest possible way... and remember that in mode7 we are not using a 80x60 display but a more flexible one with scanline resolution so first of all we would need to calculate how much plotted pixels we are talking about?

 

if we have this number we can caculate how much ram would the precalculated rendering routine would need. than we see how much cycles are left to implement a more flexible one than the mentioned fixed one. and we know how long these routine would be and then we can think about reusing the mapper for more than 1 angle for the turns...

 

and... if we are talking about using others than mode9/10 or 11... remember that code size doubles plus ram usage for the textures is 4x... (LDA ORA ORA ORA STA).

 

just my 2 cents.

 

Personally I don't think it's doable at an interactive frame-rate, if it was the demo guys would have got there already.. I mean that'd be a major flag waving ceremony for getting that one done, and at a fast enough rate, and it's not as if they're not versed in the art of writing compilers specifically for generating the code for these kinds of things.. It's simple on the surface.. It's just 'constant-Z texture mapping', but it'll be brutal in terms of code-size at any reasonable resolution, and horrendously slow..

But prove me wrong please ;)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...