Jump to content
IGNORED

Atari v Commodore


stevelanc

Recommended Posts

I've always wanted to see how well a mode 7 floor could be done on the A8. I'd settle for 10-15 fps if it worked. I figure the 160x96 mode is best for that kind of thing (might come out well in GITA modes too).

 

 

 

Yeah. For the main screen double scanline resolution and for the some enhancement, multiplexed PM graphics.

 

Do you actually know how to write a mode7 routine? I don't think you'd get it fast enough with a resolution that would be worthwhile. The only way I can see to do it (if you read my last post) is to do solid filled squares. So it's kind of Ballblazer but in mode7.

 

 

Pete

Link to comment
Share on other sites

Those things learned would tee up an interesting follow on compo, perhaps with the same title. I would love to put a 32K propeller in that mix, perhaps with SD card / eeprom asset / level file size limit, after having seen an idea of how to really put the whole show together.

I'm not sure I see where a modern 32K propeller fits.

 

*I* would like to see the "competition" approached a little differently than some people might agree with.

I'd like to see it approached like a software house might have done or might do today.

Share design and code resources where possible, trying to turn out the best possible product for all machines.

I wouldn't want to see one machine winning because one team saw a cool 6502 trick that the other team didn't.

I'd rather let the rest of the hardware be the limitation.

If you compete with machines with different CPUs then you have to allow people to optimize for it and you wouldn't have to use the same CPU code unless you wanted to but the development would have to be open. That would also imply some shared discussion between teams without arguments.

Let the results speak for themselves instead of the trash talk.

 

But I doubt that's possible... professionalism will probably take a back seat to fanboyism.

Link to comment
Share on other sites

 

I've always wanted to see how well a mode 7 floor could be done on the A8. I'd settle for 10-15 fps if it worked. I figure the 160x96 mode is best for that kind of thing (might come out well in GITA modes too).

 

 

 

I just started typing about this, and carried on and on typing, then read it back and realised it was probably really boring to read so I deleted it and will now post...

 

No way. :)

 

That's only if you don't cheat. I used to think something like Yoomp! was impossible.

Link to comment
Share on other sites

 

I've always wanted to see how well a mode 7 floor could be done on the A8. I'd settle for 10-15 fps if it worked. I figure the 160x96 mode is best for that kind of thing (might come out well in GITA modes too).

 

 

 

I just started typing about this, and carried on and on typing, then read it back and realised it was probably really boring to read so I deleted it and will now post...

 

No way. :)

 

That's only if you don't cheat. I used to think something like Yoomp! was impossible.

 

I suppose there might be "some" way of cheating, but I've been seeing Yoomp style stuff on C64 for years, a company I worked at back in the 80s had something running on C64 that dare I say pissed on Yoomp, so there are cheats for certain things, but we're talking "almost" a full 3d texture mapper. Like I said to emkay, reduce the source resolution down to squares and it becomes a lot faster so if that's what you're looking for then "maybe", but still slow. Ballblazer just moves the lines left/right with LMS, you've got to "plot" them to make it mode7.

 

*edit*

Damn it man, you've got me contemplating possible cheats and writing scalable test code now :P

 

 

 

Pete

Edited by PeteD
Link to comment
Share on other sites

Ballblazer just moves the lines left/right with LMS, you've got to "plot" them to make it mode7.

 

That's what I do with my ballblazer port for the 2600. It plots tiles from a little map. Each tile is a byte in rom so the tiles could be any color.

 

Then imagine that with a near 3d rotation calculation and a 2 dimensional offset in the map calculation for each pixel.

 

*edit*

I saw your Ballblazer stuff a while ago, btw. Beautiful :) I think I said somewhere in this thread I'd have died if I'd seen that back in the day.

 

 

Pete

Edited by PeteD
Link to comment
Share on other sites

Those things learned would tee up an interesting follow on compo, perhaps with the same title. I would love to put a 32K propeller in that mix, perhaps with SD card / eeprom asset / level file size limit, after having seen an idea of how to really put the whole show together.

I'm not sure I see where a modern 32K propeller fits.

 

*I* would like to see the "competition" approached a little differently than some people might agree with.

I'd like to see it approached like a software house might have done or might do today.

Share design and code resources where possible, trying to turn out the best possible product for all machines.

I wouldn't want to see one machine winning because one team saw a cool 6502 trick that the other team didn't.

I'd rather let the rest of the hardware be the limitation.

If you compete with machines with different CPUs then you have to allow people to optimize for it and you wouldn't have to use the same CPU code unless you wanted to but the development would have to be open. That would also imply some shared discussion between teams without arguments.

Let the results speak for themselves instead of the trash talk.

 

But I doubt that's possible... professionalism will probably take a back seat to fanboyism.

 

 

Maybe a PC 8bit testbed could be done. Write the "game" in C so fairly rapid prototyping/dev and a nice simple language that converts well to asm. Then each side can then convert to their own cpu (sharing if we're talking A8 Vs C64). That also might give the non assembler coding guys a chance to get into the game logic if they've done some C. We also get a working PC game that someone could update the graphics for a Retro Remake :)

 

 

Pete

Link to comment
Share on other sites

If you compete with machines with different CPUs then you have to allow people to optimize for it and you wouldn't have to use the same CPU code unless you wanted to but the development would have to be open. That would also imply some shared discussion between teams without arguments.

Let the results speak for themselves instead of the trash talk.

 

But I doubt that's possible... professionalism will probably take a back seat to fanboyism.

 

We-ell... we're not professionals (at least, not in the sense you're talking about) but i'm perfectly happy to talk with other programmers and share knowledge regardless (i prefer not to show my source code, but that's because it's usually a rats nest of self mod and faintly embarassing!). At least some fanboyism gets left at the door when we go from talking about code to actually trying to produce a working project.

Link to comment
Share on other sites

Maybe a PC 8bit testbed could be done. Write the "game" in C so fairly rapid prototyping/dev and a nice simple language that converts well to asm. Then each side can then convert to their own cpu (sharing if we're talking A8 Vs C64). That also might give the non assembler coding guys a chance to get into the game logic if they've done some C. We also get a working PC game that someone could update the graphics for a Retro Remake :)

 

Someone else'll have to do the C64 side of things to start with then, i wrote a game in C++ once but it was more by luck than judgement! =-)

Link to comment
Share on other sites

Maybe a PC 8bit testbed could be done. Write the "game" in C so fairly rapid prototyping/dev and a nice simple language that converts well to asm. Then each side can then convert to their own cpu (sharing if we're talking A8 Vs C64). That also might give the non assembler coding guys a chance to get into the game logic if they've done some C. We also get a working PC game that someone could update the graphics for a Retro Remake :)

 

Someone else'll have to do the C64 side of things to start with then, i wrote a game in C++ once but it was more by luck than judgement! =-)

 

Writing a game in C++ is as masochistic as 8bit asm ;) I've written plenty of stuff in C (games, apps etc) and just opening a screen on PC (or using SDL so it can be cross platform) and then writing some sprite routines/scrollers/etc to draw to it is simple. That way any of the graphics and things can be dropped into levels etc on the PC nice and easily without even the need for conversion apps. Any data (levels, waveforms etc) would have to be in the format thats needed for the 8bits. It's kind of what I've got planned for Fist cuz Ste wants a "proper" PC version :) There are a couple of remakes but they're not up to scratch.

 

I really should dig through my old backups and find somewhere safe to keep all my code cuz I've already got all this PC side stuff done about 10 times over and I always lose track of where I've put it :(

 

 

Pete

Link to comment
Share on other sites

Those things learned would tee up an interesting follow on compo, perhaps with the same title. I would love to put a 32K propeller in that mix, perhaps with SD card / eeprom asset / level file size limit, after having seen an idea of how to really put the whole show together.

I'm not sure I see where a modern 32K propeller fits.

 

 

 

It's got many RAM / Compute challenges, not unlike those found on these machines. 32K goes damn quick, all things considered. Lots of compute there, but not a lot of room, meaning there are trade-offs all over the place. I didn't mean it as a this versus that kind of thing. That's not appropriate, though I suspect the 8 bit machines could give it, and most other micros, with smaller memory footprints, a run for the money.

 

And where I was headed was down the road of bringing some retro forward onto appropriate devices. Micros, other 8 bits, etc... Some of that has crept into the demo scene, and the results so far have been interesting and challenging. Retro style gaming, demos, computing maps very well to these kinds of devices.

 

One of the challenges faced by those people into this stuff, is seeing how to do it smaller scale. It would be fun to map that over to a modern device and push it at little, that's all.

Edited by potatohead
Link to comment
Share on other sites

*edit*

Damn it man, you've got me contemplating possible cheats and writing scalable test code now :P

Here's the thing... if your resolution is 160x96, and your floor goes 2/3 of the way up, then you're talking a 160x64 which is about 10K pixels. If you use a GTIA mode, then you can cut that in half as long as you keep the line doubled mode. The line doubled mode also frees up a bunch of CPU time.

 

Now, the only way I can really see to draw the screen is to project backwards from each row of pixels into a source image. If the image is a big bitmap then you can use a line algorithm to extract pixels from it. If it's made up of tiles then there's a lot more work at the seams. Of course, maybe the data could be interleaved in a way that eliminates some of the shifting. Of course, having a ton of memory and some pre-rotated bitmaps would be nice. Making this work is all about finding the killer hack.

Link to comment
Share on other sites

We-ell... we're not professionals (at least, not in the sense you're talking about) but i'm perfectly happy to talk with other programmers and share knowledge regardless (i prefer not to show my source code, but that's because it's usually a rats nest of self mod and faintly embarassing!). At least some fanboyism gets left at the door when we go from talking about code to actually trying to produce a working project.

IF you document your code and format it decent then self modifying code isn't a big deal.

If you don't then you have a right to be embarrassed. :D

Link to comment
Share on other sites

Regarding M7, how about a ray-casting cheat.

 

Normally, when you use ray-casting for something like Wolf3D, you look up a stripe of bitmap for each pixel column on the wall. All you have to do then is scale it vertically. Well, if we consider our floor to be that wall then we have have to re-refine what a column is, but we may be able to make LUT's that allow for fast drawing operations.

Link to comment
Share on other sites

Playstation 2 being Playstation 1 compatible had ZERO impact on sales...because PS2 games actually looked different and gave their customers what they wanted...better looking/sounding games for their investment in the new machine in the series ;)

 

Well, perhaps TO YOU it had ZERO impact on sales, and perhaps to others as well. Personally, I had (still have) a huge PS1 library and was really glad it played them. Backward compatibility has a different value to different people. If any thing is of ZERO value then you'll never hear of it as an issue, because nobody will be talking about it. [1] When the PS3 dropped backward compatibility, there was (and is) lots of bitching about it - do a search and I'm sure you'll find it even on Atari Age. Hell, I'm still less-inclined to get one although I will eventually, when it's cheap enough and used games pile up in the pawn shops cheap enough. If it is of ZERO importance to everybody, why all the bitching? [2] When the DSi came out without GBA backward compatibility, some people still bitched. [3] Although they finally quit the updates, Microsoft put a substantial effort into building some software backward compatibility for the 360. If it meant ZERO to everybody, why would they have done this?

 

There's no point in arguing HOW important backward compatibility is, because it means something different to different people. However, I submit that it is not ZERO or you'd never see it, and never hear anyone bitch when it is taken away.

Link to comment
Share on other sites

Regarding M7, how about a ray-casting cheat.

 

Normally, when you use ray-casting for something like Wolf3D, you look up a stripe of bitmap for each pixel column on the wall. All you have to do then is scale it vertically. Well, if we consider our floor to be that wall then we have have to re-refine what a column is, but we may be able to make LUT's that allow for fast drawing operations.

 

 

I'd say ask Sheddy for a working game. After finishing Space Harrier....

Link to comment
Share on other sites

Care to entertain a small digression and expand on that just a bit? What do the lookups look like? Just curious.

Well, I'm still thinking about it. :) Okay, how about this:

 

The biggest line (row) in terms of source data is the top one. We calculate a reference line path through the source based on its X,Y,Z.

Now, each successive line can be defined as a smaller version of that path with an X,Y offset. What you're really doing is stepping though the line in smaller increments and clipping off more of the ends. This gives me some hints about how the reference line should be stored to increase it's resolution toward the middle... It's like how you store an image for infinite zooming...

 

In the end we'll need to be drawing nearly 2000 pixels per frame to approach 10fps, so I'm not sure it can be fast at all without a better trick.

 

EDIT: It may also be faster to draw the up close & blocky lower portion of the screen using a different method that can repeat pixels quickly.

Edited by Bryan
Link to comment
Share on other sites

...Well so far there's you, Heaven, Pete, me and maybe GroovyBee by the look of things...? That's not a bad start actually, but we should probably keep generally pontificating for a couple of days to see who else wants to step up, after all some of us are in different time zones.

 

(And yeah, the 7800 stands a good chance of winning hands down... but that's not the initial point of the exercise, it'll still give us a nice bit of C64/A8 comparison. =-)

I would get involved definitely, and both platforms are ok to me...

I have some routines for software sprites and texture maping on C64 as work in progress and am messing with GTIA modes and 3d on A8 so I'm up for challenge.

 

And I like JamesD's idea to share code or at least share general methods and algorithms. This whole thread is one big comparisson of special features of A8 and C64. And by now we know at least in theory what those are, so lets see how do they measure up in real application. If someone shows a game that looks better on one computer, someone from another team will dissasemble it anyway or simply ask "how did you do that?" and use that sort of code (if its usable) to improve his version.

Yes, it will come later, and someone will say "we were first..." but final result is true as it gets.

 

It seems to me ideas are more important than actual code, like the code in middle of A8 YOOMPs tunnel mapper, or screen drawing in C64 Last Ninja ... Those are ideas that could be used on other computer with similar effect...

 

Happy coding! :)

Link to comment
Share on other sites

Care to entertain a small digression and expand on that just a bit? What do the lookups look like? Just curious.

Well, I'm still thinking about it. :) Okay, how about this:

 

The biggest line (row) in terms of source data is the top one. We calculate a reference line path through the source based on its X,Y,Z.

Now, each successive line can be defined as a smaller version of that path with an X,Y offset. What you're really doing is stepping though the line in smaller increments and clipping off more of the ends. This gives me some hints about how the reference line should be stored to increase it's resolution toward the middle... It's like how you store an image for infinite zooming...

 

In the end we'll need to be drawing nearly 2000 pixels per frame to approach 10fps, so I'm not sure it can be fast at all without a better trick.

 

EDIT: It may also be faster to draw the up close & blocky lower portion of the screen using a different method that can repeat pixels quickly.

 

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.

 

 

 

Pete

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.. :(

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...