Jump to content
IGNORED

Atari v Commodore


stevelanc

Recommended Posts

Because Commodore has all these hardware tricks, does it make the system better then atari...and visa versa

 

Let's create a level playing field, pick a commodore hardware trick or tricks that CAN be simply or easily replicated on the atari

 

Create some games for both systems employing said hardware trick or tricks

 

and let the consumer/user decide on which machine is better based on the same game on both systems

 

If not this way, create a commodore/atari platform using the same gfx/sound hardware but based on existing o.s routines

 

create some games employing full use of the sound/gfx hardware (including any or all hardware trickery) for both systems

 

and let the user/consumer decide on which machine is better based on the same game on both systems

 

I think Allas (or was it Philsan) had a similar idea (in keeping with the OP's original post and point) by looking at the atari and commodore versions of the same game

 

That's the best way to decide this argument...or failing that...MSX vs Amstrad (2 very similar systems)

 

 

Untill then i'm off to play with my a1200 enhanced 1tb HD upgraded 256mbyte p/s 256bit cpu with 128 gig of memory sinclair spectrum x 256 (I'm using version 1a at the mo, Sir Clive is working with the 'god' of hardware design , one Mr Miner on creating version 2...and it plays a mean game of SR)

Edited by carmel_andrews
Link to comment
Share on other sites

What I'm interested in is finding a good source of technical info on the atari, different modes, methods of producing more colours on screen, cpu time available etc because I quite fancy having a go at replicating the enforcer demo (or at least something very like it) on Atari.

Hello Pete!

I'm also C64-oriented but came to this great forum last year...

Now I have manuals, hardware and good will to do something with it :)

 

Take a look at these:

 

http://www.atariarchives.org/

 

"Atari graphics and Arcade game design" and "Compute!'s Second Book of Atari Graphics" were best read for me....

 

And cpu timing diagrams here:

 

http://www.atariage.com/forums/index.php?s...0&hl=timing

 

Good luck!

Link to comment
Share on other sites

Because Commodore has all these hardware tricks, does it make the system better then atari...and visa versa

...

If a hardware trick on Atari or C64 works consistently then it's as good as a feature. If it causes system to become unstable or locks up some machines, I don't consider it worth much.

 

>Untill then i'm off to play with my a1200 enhanced 1tb HD upgraded 256mbyte p/s 256bit cpu with 128 gig of memory sinclair spectrum x 256 (I'm using version 1a at the mo, Sir Clive is working with the 'god' of hardware design , one Mr Miner on creating version 2...and it plays a mean game of SR)

 

Too many acronyms-- what's SR and a1200?

Link to comment
Share on other sites

Because Commodore has all these hardware tricks, does it make the system better then atari...and visa versa

...

If a hardware trick on Atari or C64 works consistently then it's as good as a feature. If it causes system to become unstable or locks up some machines, I don't consider it worth much.

 

>Untill then i'm off to play with my a1200 enhanced 1tb HD upgraded 256mbyte p/s 256bit cpu with 128 gig of memory sinclair spectrum x 256 (I'm using version 1a at the mo, Sir Clive is working with the 'god' of hardware design , one Mr Miner on creating version 2...and it plays a mean game of SR)

 

Too many acronyms-- what's SR and a1200?

 

A1200 is an Amiga, no idea what game SR is when it's at home.. The only game I recall that fits the bill could be Space Rogue ;)

 

Oh, and PeteD (or should I say JCB :) ), I like your ideas and too some degree agree with you on Enforcer 2, but I do still think E2 is a lovely bit of code, even though it looks on the surface fairly straight forward given the 64s hardware.. I'd be happily alongside you with doing something like that on the A8s, but the thought of learning the ins and outs of *yet* another 8bit machine fills me with dread, if only from what the missus would say ;)

 

It's good to see you're still alive and have still got the 8bit bug, and are here :)

Edited by andym00
Link to comment
Share on other sites

Thanks for all the welcomes and the links to info, I'll download it all and start reading. I don't know when I'll get time to do anything, work wise I'm all quiet at the moment but I've got to decorate/tidy/pack up my house so I can sell it.

 

Like I say bout Enforcer, I've not looked at the code, I'm not bashing the coders but honestly I wouldn't rank it anywhere near the best c64 games either graphically or technically. I've shown it to a couple of other "old school" c64 people and they agree. It doesn't help that I keep reading a lot of hype about it like it's as good as an amiga game or a dual 68000 arcade machine lol please. If it plays well then thats all for the good but it isn't doing anything any more complex than games were in the 80s. But anyway, I'm repeating myself and I don't want to go in depth on the technicalities of Enforcer. My main point was, apart from colours I'm not seeing anything the Atari can't do. I've read a couple of calculations for the amount of cpu time free on the Atari compared to c64 and I think the Atari would have enough time to do most of the sprites from the c64 version in software. It all then depends on what methods could be used to add some more colour and how much cpu they steal.

 

I'm sure there are a lot of talented coders on this forum and the fact nobody has just replicated enforcer 2 demo yet (just to stop this constant "you can't do it" stuff) makes me think that to trick the hardware into producing enough colours wouldn't leave enough cpu to run the sprites/collision detection/game logic etc Then it all comes down to does a game have to have lots of colours to be a good game?

 

Thinking about it, one plus for using software sprites over the C64 hardware ones is whilst masking (I use graphics data and a mask of the same size, yeah more ram but faster) you can also mask areas that would be transparent on c64 but on Atari if the mask is set the background wouldn't get drawn "through" them so in a way you're gaining a colour. You can also add an outline to the sprite in the same way using just the mask to make it even more visible. I think something like that would be needed if the sprites had to be the same colour as the background.

 

 

This is what I love about coding, especially low level stuff. The possibilities for optimising code/methods are almost endless and I find it fun to think up new ways to do things. When I was writing Splam (c64 emu for gba) I rewrote the screen rendering code countless times and ended up with something that could draw and scale the c64 screen in any mode down to the gba screen size faster than the gba could draw and scale it in hardware.

 

Pete/JCB ;)

Link to comment
Share on other sites

I love to have some c64 coder coming over and touching the evil... Graham did already some work which I have on my hard disc but I am not allowed to publish (while he was teaching me chunky modes on c64) and I am only aware of TMR of cosine who has touched nearly every 6502 machine... ;)

Link to comment
Share on other sites

PeteD/JCB, It's excellent to have another experienced 6502er here. As you have been around the 8-bit world productively so long, I'm sure you'll immediately enjoy working with the A8. We are all here for any specific Atari technical info questions. I'd recommend downloading Tebe's MADS assembler which includes a lot of sourcecode examples too. A recreation of Enforcer would be awesome. I'd be very interested to see what someone with such good credentials can produce! There are some good A8 coders around but as a whole the A8 scene is lacking on the amount of coders so I hope you stick around and get into the Atari scene.

Link to comment
Share on other sites

Thanks for all the welcomes and the links to info, I'll download it all and start reading. I don't know when I'll get time to do anything, work wise I'm all quiet at the moment but I've got to decorate/tidy/pack up my house so I can sell it.

 

Like I say bout Enforcer, I've not looked at the code, I'm not bashing the coders but honestly I wouldn't rank it anywhere near the best c64 games either graphically or technically. I've shown it to a couple of other "old school" c64 people and they agree. It doesn't help that I keep reading a lot of hype about it like it's as good as an amiga game or a dual 68000 arcade machine lol please. If it plays well then thats all for the good but it isn't doing anything any more complex than games were in the 80s. But anyway, I'm repeating myself and I don't want to go in depth on the technicalities of Enforcer. My main point was, apart from colours I'm not seeing anything the Atari can't do. I've read a couple of calculations for the amount of cpu time free on the Atari compared to c64 and I think the Atari would have enough time to do most of the sprites from the c64 version in software. It all then depends on what methods could be used to add some more colour and how much cpu they steal.

 

I'm sure there are a lot of talented coders on this forum and the fact nobody has just replicated enforcer 2 demo yet (just to stop this constant "you can't do it" stuff) makes me think that to trick the hardware into producing enough colours wouldn't leave enough cpu to run the sprites/collision detection/game logic etc Then it all comes down to does a game have to have lots of colours to be a good game?

 

Thinking about it, one plus for using software sprites over the C64 hardware ones is whilst masking (I use graphics data and a mask of the same size, yeah more ram but faster) you can also mask areas that would be transparent on c64 but on Atari if the mask is set the background wouldn't get drawn "through" them so in a way you're gaining a colour. You can also add an outline to the sprite in the same way using just the mask to make it even more visible. I think something like that would be needed if the sprites had to be the same colour as the background.

 

 

This is what I love about coding, especially low level stuff. The possibilities for optimising code/methods are almost endless and I find it fun to think up new ways to do things. When I was writing Splam (c64 emu for gba) I rewrote the screen rendering code countless times and ended up with something that could draw and scale the c64 screen in any mode down to the gba screen size faster than the gba could draw and scale it in hardware.

 

Pete/JCB ;)

 

I beg to differ, there is more going on in the asteroid screen level of Enforcer 2 than any other C64 or any 8bit game as far as number of independent moving objects are concerned (the huge asteroids, the connecting rods between the asteroids, the missiles/lasers shot, the enemy ships). The resolution/colour depth may not be the same as a 68000 based Konami/Irem arcade game but the sheer number of things moving on screen is just as high in sophistication.

 

Feel free to code something better from that point of view with 3 layers of OVERLAID (ie 3 playfields) type parallax at any time though now that you have decided it is mediocre 1980s level of coding sophistication. I look forward to your youtube video of better coding in the very near future ;)

Link to comment
Share on other sites

Because Commodore has all these hardware tricks, does it make the system better then atari...and visa versa

 

Let's create a level playing field, pick a commodore hardware trick or tricks that CAN be simply or easily replicated on the atari

 

My only problem with this is that it will have no bearing on which is the best machine, which by definition is the one which has the best compromise overall.

 

The point is the A8 version of Rescue on Fractalus can only be achieved on A8 hardware, ditto a carbon copy of Last Ninja from the C64 is going to be nigh on impossible. So it depends why you would want to do this really?

 

The differences between the two machines are what give them their strengths (and weaknesses) and ultimately the best machine is surely going to be the one with the least impacting weaknesses compared to their strengths in any given scenario you want to place them (as a serious business machine or a games machine or a music system or a slide show player etc etc)

 

(I don't think Last Ninja is really that sophisticated a game technically anyway, certainly not as unbelievable to watch as Salamander on the C64)

Link to comment
Share on other sites

I don't know why you're so excited about that Enforcer demo.

 

Most of the moving objects are doing so on a character boundary basis.

 

Using that method on the A8, you could probably get 50% or more "objects" moving around, given the faster CPU and not needing to expend many cycles to do scrolling.

 

That aside, the "game" isn't worth a pinch of shit until it's something you can actually play.

Link to comment
Share on other sites

@oky2000 Sorry, I was under the impression from what I have read of this thread that it's the Enforcer 2 level 2 demo that everyone was touting as the best thing since sliced bread but I'll respond anyway as you obviously know more about c64 coding than me. As far as my "coding the c64 since 1985" brain sees it, it's the same as level 2 ie nothing groundbreaking, 8 hardware sprites for the aliens (the skulls and animating ships) the huuuuuge asteroids and many layers of parallax are all a character based scroll (something that every game does) with some parallax routine to make the star background), character based sprites to do the fast moving background strip (2 character wide star) things and player bullets. Why you mention the asteroids and the rods connecting them as two different things I don't know, they're the same screen mode, character based just like the A8 can do. As I said before, nothing new, nothing anywhere near as complex as lots of games have been in the past. Your "feel free to code something better" taunt seems nothing more than that of someone who doesn't know that it is in fact easy to do and would be a waste of my time. I'm here because I'm interested in doing some A8 coding not to prove what I already know about my own c64 coding skills ;)

 

I'll just break down whats going on with either Enforcer level and how much cpu it would take on the c64. First, full screen scroll, well pixel per frame so you've got 8 frames to build the next screen. Maybe 1/8th frame cpu. 8 hardware sprites, negligible, just the time to set the hardware registers. Parallax, as it's mostly slower than the screen scroll you've got even more time between changes than the 8 frames to do the screen (funny that how everything is spread out over lots of frames) you can either rotate the data through a couple of characters per "depth" or just store the pre rotated data and dump it lda,sta style into the characters. So far we're up to maybe 2/8ths of available cpu time per frame. The bullets, character based, character boundary movement, no masking with the background, so you've got the time it takes to work out their position on screen, store a byte to screen ram, then clean them up afterwards for the next frame. The volume of the char based sprites is the only thing that takes cpu time in this instance but even then you're not going to be using more than 1/2 a frame cpu for everything so far. Add to that music/sound effects code, max another 1/8th frame, game logic, not much going on, get some attack patterns from a table when the level position reaches a certain value, check for collisions (course checking first with char based bullets would be fastest). And that's my breakdown of what is going on. Basically if the Armalyte coders had thought the background would've looked prettier with a char boundary parallax scroll I'm sure they would've done it and then you'd be using that as your technical masterpiece and in that instance I'd be a bit more inclined to agree.

 

 

I don't know you, don't know if you're a coder or just a user, am not here to get drawn into an argument or have to prove myself to you (no offence but if you were someone I knew and respected as a coder I'd take up your challenge). You're entitled to your opinion, despite it being wrong ;) If I get time to code anything it will be a conversion of Enforcer to the A8 to prove people wrong NOT a whole game on c64 to prove YOU wrong. Of course if you want to do the graphics for a whole game and send those to me I'll be happy to write a game with them and sell it, make myself some money maybe :)

 

This is (hopefully) my final post on the c64 version of Enforcer. I know how its all working, I'm not terribly impressed on a technical level, if you don't agree how about you prove to me (explain it in technical terms like I have) how it's so amazing, don't just tell me "hey, its better than you could do, dare you to do better".

 

Pete

 

In fact, I'll add an edit here. As both machines are 6502 and I'm more familiar with the C64 architecture I might do some of the code (logic, scroller, parallax, software bullets, player/enemy movement) on c64) basically as much as is possible to reuse on A8 (did you notice I learned you can call it A8 and I don't have to keep typing Atari all the time? lol) Not sure what to do about graphics as it seems pointless asking someone to do a whole set of c64 ones to prove a point to one person then another set to conform with however I do the A8 as far as colour production goes. Still, any offers for some multicolour char backgrounds would be welcome. If you're reaaaaly unlucky I'll draw them myself lol

Edited by PeteD
Link to comment
Share on other sites

Yeah, I noticed that. I'd read it somewhere and it had stuck in my mind and then when I started thinking about software sprites and how fast you could make them and so relating to how many you could plot on screen I suddenly thought, hold on, there wont be enough characters available to plot all the sprites into, at least if u make them c64 size. Isn't there some way to split the screen into say 4 vertical areas and use a different char bank for each one? That to me is a c64 concept which would work easily but I don't know if it's possible on A8. The backgrounds themselves don't seem that complex but it certainly wont leave enough for sprites too, unless you move them on char boundaries and don't mask/or with the background and that would just look nasty ;)

Link to comment
Share on other sites

You can very easily split the screen into horiz strips with separate fonts utilising a dli. The half set can make things a little more tricky to conceive the game then it otherwise would have but I like to think it's always possible to work out a solution.

Edited by Tezz
Link to comment
Share on other sites

Also worth mentioning that one of the challenges to overcome with the A8 is with the half char set.

 

Is this really a "Problem" except the higher memoy usage?

For most games you'd have to use 3 128 char sets. Use up to the half of them with the same content, so you don't have to take care of the DLI lines. The rest of every charset can be used for filling up the background graphics then...

If you need more moving objects, you have to use more charsets...

Link to comment
Share on other sites

my Beyond Evil WIP softsprite routine works with 7 Charsets changed every 3rd charline. As you don't rely on VIC banks you can have virtually as much charsets as you want...

 

every 4th line simply because when you are using standard screensize with 40x chars then my layout looks like this

 

ADG -- DLI

BEH

CFI

ADG -- DLI

BEH

CFI

...

 

As Oswald would go down this road, too and this method occupies 120x chars leaving 8 chars for bullets...

Edited by Heaven/TQA
Link to comment
Share on other sites

http://www.atariage.com/forums/index.php?s...Evil&st=525

 

on the last page you see my example... but with bugs still... by pressing START/SELECT you can see the backbuffer...

 

the draw room is not perfect and is not speed optimised so use a slow for rows=0 to 23:for collums=0 to 39:jsr clear_char_in_font_at_collums_rows:next:next

Link to comment
Share on other sites

Also worth mentioning that one of the challenges to overcome with the A8 is with the half char set.

 

Is this really a "Problem" except the higher memoy usage?

For most games you'd have to use 3 128 char sets. Use up to the half of them with the same content, so you don't have to take care of the DLI lines. The rest of every charset can be used for filling up the background graphics then...

If you need more moving objects, you have to use more charsets...

It depends also on the complexity of the background graphics and amount of software sprites. When we were working on BombJack for instance we had to conceive a formula for the charset usage .. x amount of fixed chars on each font in the dli for the background gfx, x amount for the constant chars such as ledges, bomb definitions etc, and the rest for the software sprite use. The number of software sprites moving freely across the multiple fonts down the dli determins how many free chars we have left for the backgrounds and fix chars. I was able to achieve a final result in the end for the game after several months of work and redesign although if we had a complete charset, the 3rd screens background for example would have been able to have the trees spread as I had originally planned them.

 

It's possible to find an acceptable compromise/solution if you're committed to completing a project.

Edited by Tezz
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...