ATARISH

[Idico]

Atarish means to me (what it means to you?):

 

Player/missile graphics - including 3 shade objects build from pairs of players, if objects are low resolution because they need to be big we save memory for better animation (great!)

 

PM under and overlays - 160x200 in 11 (is it posibble when using PM technique described abive ?) colors per scanline (without mid line colour changes) or this interesting feature when using high resolutution graphics

 

Overscan - if you want 17" display then buy 21" TV (not true when playing Atari!)

 

console keys - nothing special ?, want some help so press HELP key

 

colours - we have plenty (256) of them so we should show what we have

 

speed - Atari is faster then for example C64 unless we use the processor power to emulate C64 hardware features, for example sprites or SID (which I have nothing against until we use what is left but planning 8 12x16X4 sprites for an Atari game is in my opinion mistake)

 

hardware scrolling - played once Zybex on Spectrum, can you belive that the screen is constantly changing its width due to the horizontal scrolling

 

 

I definatelly would like to see more of the above features in new games.

[TMR]

I definatelly would like to see more of the above features in new games.

 

Feel free to jump in and start coding, then...? =-)

[Idico]

Some examples to ilustrate what Iam talking about:

 

Player/missile graphics - Cavernia, ghost and belly thing with long neck and Mario in Mario... from Analmux

 

 

PM under and overlays - title screens in G2F thread and ... Armalyte for the c64 (it should be an Atari game!)

 

 

Overscan - Cavernia again (and many others to some extent)

 

console keys - almost every Atari game I suppouse (but Analmux Mario demo used it reminded us we do have the HELP key)

 

colours - many games change colors in DLI but also color shemes in Cavernia or Boulder Dash

 

 

speed - it's hard to judge CPU usage but I think that full screen Boulder Dash is possible on Atari since c64 is just as much slower as Atari's big screen is bigger then C64 standard screen

 

hardware scrolling - especailly in cardridge games when we can save CPU clocks by building the whole level in memory and scroll using Antic only (probably many games do this)

 

 

TMR:

Feel free to jump in and start coding, then...? =-)

 

 

If any of you like the features in the above games I surely will.

[TMR]

Armalyte for the c64 (it should be an Atari game!)

 

Armalyte plays heavily on the C64's specific hardware, so unless you're planning on going back on yourself and handling up to 24 12x21 pixel four colour objects (you said 8 12x24 sprites was a mistake) it's very specifically a C64 title. If you just want to do something sort of like it, that's a different matter but getting that many 4 colour objects moving without restrictions even at 8x16 is going to prove problematic.

 

console keys - almost every Atari game I suppouse (but Analmux Mario demo used it reminded us we do have the HELP key)

 

There's no point in using them unless you have a reason to use them. Reaxion A8 uses the start key to pause the game, but it doesn't need any other functions during play.

 

Feel free to jump in and start coding, then...? =-)

 

If any of you like the features in the above games I surely will.

 

Why look to anyone else instead of just coding a game using some or all of the above to show everybody what they're missing? When i started Reaxion A8, i decided that i wanted a playable game with a reasonable amount of colour onscreen, a larger than average sprite object and some decent soundtracks to top it off and i'd like to think we achieved that with the final result.

 

i'm starting to toy with ideas for the next project now; i already have one tune of a soundtrack from Sean/Cosine and i've got theories that need some testing that can possibly put quite a few more colours onto a line than i did previously. But i've not written a byte of actual code because i don't want to just turn it into a tech demo with nothing behind it and i haven't got any kind of game logic worked out yet.

[Idico]

[TMR wrote:] Armalyte plays heavily on the C64's specific hardware

 

Doing this game the way its done on c64 dosen't make sense. But I think it is possible to have even more action (bigger screen) using limited number of precalculated tiles in character graphics and just to color them using PM underlays

 

[TMR wrote:] Why look to anyone else instead of just coding a game using some or all of the above to show everybody what they're missing?

 

Not much fun doing something just for myself. If even only a lost C64 coder is intrested I write a game to show the above and also good lo-res animation (Zybex , Pacem in Terris demo)

[emkay]

[TMR wrote:] Armalyte plays heavily on the C64's specific hardware

 

Doing this game the way its done on c64 dosen't make sense. But I think it is possible to have even more action (bigger screen) using limited number of precalculated tiles in character graphics and just to color them using PM underlays

 

[TMR wrote:] Why look to anyone else instead of just coding a game using some or all of the above to show everybody what they're missing?

 

Not much fun doing something just for myself. If even only a lost C64 coder is intrested I write a game to show the above and also good lo-res animation (Zybex , Pacem in Terris demo)

 

 

 

Sometimes I ask to myself, why a game never was created, the best way a game could have been created on the A8...

 

1st : Creating the main sprite by software

2nd : Using Charmode for fast movement

3rd : Using PM graphics for the enemies and "overlay" or "underlay"

[Heaven/TQA]

i would go the opposite way... using all pm for main sprite for good colour/resolution and then charmode for enemies... i hate monochrome enemies and just 8 pixel wide...

 

see dropzone,pastfinder f.e.

 

i do not like the "gr.7 games" zybex & draconus (don't get me wrong... i like the games but i hated the gr.7 "highres" 3 colour style)...

 

 

btw. i finished zybex & draconus without a trainer... so i have played them much...

[emkay]

i would go the opposite way... using all pm for main sprite for good colour/resolution and then charmode for enemies... i hate monochrome enemies and just 8 pixel wide...

 

see dropzone,pastfinder f.e.

 

i do not like the "gr.7 games" zybex & draconus (don't get me wrong... i like the games but i hated the gr.7 "highres" 3 colour style)...

 

 

btw. i finished zybex & draconus without a trainer... so i have played them much...

 

Me too

 

 

Think about this:

 

Using a Softwaresprite for the "Hero" means: CPU Time for only one Softwaresprite

 

Using PMg will be more flexible then: One Enemy with the resolution of 16*16(240) and three colours can move over the full screen.

Yourself tried a multiplexer by DLI for normal PLAYERS. By using this "trick" you can have "32" HW-Sprites on the screen with the resolution of 16*16 and 3 colours...or you try to use one Player and one missile overlay and you get 4 3 colored enemies on the same scanline as the hero...

When enemies coming through the game screen they always fly/move in a special formation... This is easier done with PM...

 

etc. etc. etc.

[Bryan]

Charmode sprites.. PM overlays... many DLI's... it all sounds very nice, but wait until you start coding it and realize all the special cases you have to handle to make it look good. Then try to get it to run at a reasonable frame rate.

 

It's not that you cannot improve on what's been done, it's just that's there a reason you don't see these complicated techniques everywhere. You need to be pretty hardcore to put in the time it takes to write a game that way. When I wrote Castle Crisis, I started out with very high expectations of what I would be able to accomplish. What I discovered is that my final approach to the game was much different from how I thought I would do it, but the result looks nice and runs at 60fps without a double buffer (so 16K machines can run it).

 

In other words, you always run up against a "practical ceiling" when it comes to graphic effects. The idea is to get as close as possible to that limit, and always be ready to throw away your code, and change your expectations when something doesn't work.

 

-Bry

[emkay]

 

In other words, you always run up against a "practical ceiling" when it comes to graphic effects. The idea is to get as close as possible to that limit, and always be ready to throw away your code, and change your expectations when something doesn't work.

 

 

An Action Game using the techniques I mentioned would run fast enough in Turbo Basic :wink: Remembering Drol that had only some slowdowns when the screen is "full" of softwaresprites.

Defining only one Softwaresprite for a scrolling charmodescreen would save time in double.

a) creating shots with missiles or char-Movement is the fastest possibility either.

b)objects with a fixed position in the level can easiely set or removed by char-movement.

c) Pm graphics is free for full "enemy"-usage

[Wrathchild]

Remembering Drol that had only some slowdowns when the screen is "full" of softwaresprites.

DROL and, for example, Universal Hero have XOR sprite engines which are naturally quicker than having to apply a mask but although they don't look too great on overlaps you can get away with them so long as you aren't using DLI colour changes profusely.

 

Regards,

Mark

[Heaven/TQA]

and remember zone ranger's "donkey kong" sprite engine... and my nearly 2 years old research in the sprite engine which is done very fast...("time pilot thread")

 

sprite multiplexing is good but unfortunatly on atari we spend for a 8x16x3 sprite 2 hardware players... and leaving 2 for gaining one more... and i am sure this limits games esp. action games...

 

and do not underestimate the time you need for vertical movement or clearing the pm area... this is an overhead which we sometimes forget...

 

is there any other computer with this "stripe" concept? i have just seen one...amiga jeff miner has choosen blitter objects and hardware sprites well known from c64...

[Heaven/TQA]

aarrg...damned martini... i ment i have NOT seen any other machine with the PM concept.

[emkay]

 

sprite multiplexing is good but unfortunatly on atari we spend for a 8x16x3 sprite 2 hardware players... and leaving 2 for gaining one more... and i am sure this limits games esp. action games...

 

 

Yes... On C64 you define just a sprite and then you can easiely set X and Y positions.

The limits on games that are created already are very much heavier than with "my ideas".

Heck.... I don't want to start a new thread with this...

 

 

and do not underestimate the time you need for vertical movement or clearing the pm area... this is an overhead which we sometimes forget...

 

The higher the sprite count, the lower is the overhead...

 

 

@wrathchild

 

I know the issue with those EOR Sprites. But I am talking about almost one Softwaresprite for the full Game.

[Idico]

What I'm thinking of is to use enemies that move fast but only by paths predictible by player (so they are not too fast to avoid or destroy). I think it could lover the memory overhead involved with precalculated sprites and create the feling of fast action at the same time.

[TMR]

Doing this game the way its done on c64 dosen't make sense. But I think it is possible to have even more action (bigger screen) using limited number of precalculated tiles in character graphics and just to color them using PM underlays

 

i don't get this; you're either wanting to do Armalyte or you're not; this is like me saying "i'm going to port Uridium to the A8 but i'm removing a few of the aliens... oh, and changing the scroll speed and...". If you want to write a hardcore shoot-em-up that's cool 'cos i love them, but if it's not going to be Armalyte why even mention the name?

 

Not much fun doing something just for myself. If even only a lost C64 coder is intrested I write a game to show the above and also good lo-res animation (Zybex , Pacem in Terris demo)

 

i'm not really that interested until i see code running, but at the same time i don't want to see games written just to prove technical points; i want to see games written because they're good ideas for games.

[Bryan]

i'm not really that interested until i see code running, but at the same time i don't want to see games written just to prove technical points; i want to see games written because they're good ideas for games.

 

Hear! Hear!

 

-Bry

[Dracon]

sprite multiplexing is good but unfortunatly on atari we spend for a 8x16x3 sprite 2 hardware players... (...) .. this is an overhead which we sometimes forget...

is there any other computer with this "stripe" concept? i have just seen one...amiga jeff miner has choosen blitter objects and hardware sprites well known from c64...

 

Is it really important to use those hardware sprites in games?

Take a look at some best hires graphix games, e.g. Starquake or Artefakt Przodkow... They're beutiful in terms of their visual quality. And there are no hardware sprites, but only well arranged (chars animated) "program sprites".

[Idico]

TMR wrote:

i don't get this; you're either wanting to do Armalyte or you're not; this is like me saying "i'm going to port Uridium to the A8 but i'm removing a few of the aliens... oh, and changing the scroll speed and...". If you want to write a hardcore shoot-em-up that's cool 'cos i love them, but if it's not going to be Armalyte why even mention the name?

 

Never said I want to port Armalyte or enything else.

Ideal platform to port everything is only PC because it gets faster every year so there are no limits but not an 8bit Atari. I think simply cloning c64 game on Atari doesn't make sense (if it is a really good game on c64 it is likely that an Atari port will be inferior when compared to the original becouse of different hardware strenghts and weekness).

I menshioned Armalyte because of its features eg color schemes used for enemies and fast action (others for the same reason - distinct features)

I want to do a shoot-em up Armalyte like only better. I think it is not a shame this days to borrow whatever you want when you are building something for a computer 25 years old and forgotten by everyone a long time age.

[TMR]

Ideal platform to port everything is only PC because it gets faster every year so there are no limits but not an 8bit Atari. I think simply cloning c64 game on Atari doesn't make sense (if it is a really good game on c64 it is likely that an Atari port will be inferior when compared to the original becouse of different hardware strenghts and weekness).

 

No, that's not right; a good game will be good regardless of the platform because it's a good game, the only difference will be how it looks and sounds and these should always be secondary. When moving stuff from one platform to another there'll always be concessions but as long as they don't affect how the thing plays they're not all that important. Reaxion A8 drops colour depth compared to the C64 original but still plays as well because it shares the core code and i'm looking forward to Analmux's Mario port because it'll make some graphical concessions but i'm expecting a lot of loving detail from him and therefore a shedload of playability to boot.

 

The C64 to A8 ports of Last V8 and Red Max drop quite a bit of colour depth, Zybex and Draconius on the A8 drop 50% of their graphic resolution and Dropzone on the C64 drops lots of cosmetic details but all of them remain playable. A good game'll still be good if you take the 20 minute soundtrack and half the colour out, a bad game'll still be bad even if you spend months overscanning it and adding tons of colour.

 

I menshioned Armalyte because of its features eg color schemes used for enemies and fast action (others for the same reason - distinct features)

 

Then you needed to be a lot more clear about that, your original wording read that you wanted Armalyte on the A8 and you didn't clarify when i questioned you on it.

 

I think it is not a shame this days to borrow whatever you want when you are building something for a computer 25 years old and forgotten by everyone a long time age.

 

i certainly don't have a problem with any of that, i happily nick stuff all the time! =-)

[Idico]

TMR wrote:

When moving stuff from one platform to another there'll always be concessions but as long as they don't affect how the thing plays they're not all that important.

 

The problem is that the gameplay is always affected. Some things like the screen size are too important to be neglected (nowadays most arcade and console games use a whole screen, why is that ?). I think also that first impression is very important so if the game is to be somehow crippled then the programmer should offer something anything instead to compnsate.

Lets look at Zybex. Spectrum version is from technical point of view somethin I cant stand. C64 version has pleanty of colors on screen at the same time but sprites are relativly to big (compared to the screen size) and there is something wrong with colision detection (too hard). Atari, version, which I like the best, has less coloros but has this softness in animation (more shades in objects ?) and better proportions.

Not that I do not like (I love it in fact) what Analmux is doing with Mario but I do not think it would be any worst when converted to the full screen. There were plenty of titles (probably any of them as fast as Analmux plans Mario to be) in the 90's from Poland and almost all limited to 512B active part of the screen (two times 256 but what a shame anyway).

 

English mode off. 6502 mode on.

[TMR]

I think also that first impression is very important so if the game is to be somehow crippled then the programmer should offer something anything instead to compnsate.

 

i don't think i've ever disagreed quite as much with anyone since i put emkay on ignore. First impression ceased to be important when the audience shifted from being the average punter in the street who needed to be impressed to people who, as with the readers here and on the boards about other 8bits, are more into actually playing games than being wowed. Yes, it's nice to have something jump out at you visually but it'll always be secondary to the majority of the people still with the A8, C64, Spectrum, whatever.

 

If the gameplay is being crippled (and that term, to me, means that it's so badly damaged the game won't play well) the project should be scrapped and not prettied up.

 

English mode off. 6502 mode on.

 

What, you haven't been running both at once...? =-)

[TMR]

Is it really important to use those hardware sprites in games?    

Take a look at some best hires graphix games, e.g. Starquake or Artefakt Przodkow...   They're beutiful in terms of their visual quality. And there are no hardware sprites, but only well arranged (chars animated) "program sprites".    

 

Starquake is probably that way because it's graphics are originally from the Spectrum version so it's easier to just port and drop colour depth (since the Speccy can do 15 colours a scanline with a few concessions) than redraw them. i can't remember playing Artefakt Przodkow but i probably have at some point (i'm not at my own computer until tomorrow, but i'll 'ave a look when i get back) but something like Kult played quite well, was very nice looking but very bland on the colour front. In theory, some PM underlays could be used to brighten things up but i'm dubious about how much is actually do-able without producing "colour clash" problems or overloading the CPU...

[analmux]

@ TMR

 

I hope you can answer this technical question (about some C64 games), cause I've heard you talk about C64 scrolling routines a while ago.

 

Do you know how many cpu-cycles the scrolling routines (including tile decompression and buffer updates) of f.e. Flimbo's Quest, Mayhem in Monsterland and the Turrican Series takes? How much time is left for other tasks?

[TMR]

Do you know how many cpu-cycles the scrolling routines (including tile decompression and buffer updates) of f.e. Flimbo's Quest, Mayhem in Monsterland and the Turrican Series takes? How much time is left for other tasks?

 

i've never really looked into anyone else's code as far as cycles required to be honest. The Turrican scroller is probably the heaviest on time requirements because it needs to be able to shift in any of eight directions, colour shifts too and there's a very heavy multiplex running at the same time; it runs the scroll at 25FPS for this reason. Flimbo's is also pretty heavy because it needs to map in the background detail before it draws the foreground stuff on (and the foreground draw needs to not plot where there are gaps so there are extra checks going on there as well) and then work out the colour map in the last frame before it needs to switch buffers. Mayhem In Monsterland is the odd one out, it's using a VSP (sometimes called DMA Delay) scroller; this only needs 48 bytes written into the screen RAM every character shift and the only time it reaches it's peak load is once every 40 characters when it has to shuffle the colour map around because the VSP has reached it's limit.

 

If memory serves, both Mayhem and Flimbo's are not multiplexing and purely relying on zone split sprites so they have more time to dedicate to the scroller.