Titus the Fox

[Creature XL]

If it only would be possible to ignore the words "digi track" and "digi music" in forum posts when a thread is about an Atari 8-bit game.

If we are talking about 4-6 soft sprites (with background ORing) and DLIs there is no room for digi music, FFS! (At least not in my book).

 

And yes, I know the Lemmings intro!

[Rybags]

Doesn't matter.

 

If lots of DLIs are in use (probably not likely in this game), they can do part of the digi-play duties with the rest served by Timers.

 

Swap out the OS and use IRQ vector direct - timers become a very efficient way of doing things.

 

Use brute-force algorithms for soft-sprites and suddenly a whole lot of CPU time is freed up. OK, it might mean a 64K game becomes a 256K one, but it can be worth the price.

[Creature XL]

Doesn't matter.

 

If lots of DLIs are in use (probably not likely in this game), they can do part of the digi-play duties with the rest served by Timers.

 

Swap out the OS and use IRQ vector direct - timers become a very efficient way of doing things.

 

Use brute-force algorithms for soft-sprites and suddenly a whole lot of CPU time is freed up. OK, it might mean a 64K game becomes a 256K one, but it can be worth the price.

Then I am quiet and go back to find the holy grail.

I have no CPU time left for digi sound with my routines (32 byte ANTIC4 screen without scrolling).

And of course my 62Kb (without OS already) is almost filled.

Further its not only the CPU... 60 seconds with 4 bit per sample and 8KHz take 240Kb uncompressed

Why am I spending time on this, I just wait till Emkay has finished the game

 

 

PS:

My soft-sprite routes are general routines (with background ORing) and partly unrolled already. I can't see much space for optimizations. Well, using "LDA #, AND #, ORA #" instead of "(),y" will help a lot, but then I am sure that 6Kb is not enuff .

[Rybags]

When he says "Digi music" that doesn't necessarily mean a digitised tune.

 

Just a couple of instrument like drum/symbol samples will be reasonably cheap.

[emkay]

Doesn't matter.

 

If lots of DLIs are in use (probably not likely in this game), they can do part of the digi-play duties with the rest served by Timers.

 

Swap out the OS and use IRQ vector direct - timers become a very efficient way of doing things.

 

Use brute-force algorithms for soft-sprites and suddenly a whole lot of CPU time is freed up. OK, it might mean a 64K game becomes a 256K one, but it can be worth the price.

Then I am quiet and go back to find the holy grail.

I have no CPU time left for digi sound with my routines (32 byte ANTIC4 screen without scrolling).

And of course my 62Kb (without OS already) is almost filled.

 

 

Hm.... Antic 4 .... isn't that the char mode with those extra bad lines?

 

And, isn't this thread about Gr. 7 ?

 

 

 

 

 

 

 

Further its not only the CPU... 60 seconds with 4 bit per sample and 8KHz take 240Kb uncompressed

Why am I spending time on this, I just wait till Emkay has finished the game

 

 

PS:

My soft-sprite routes are general routines (with background ORing) and partly unrolled already. I can't see much space for optimizations. Well, using "LDA #, AND #, ORA #" instead of "(),y" will help a lot, but then I am sure that 6Kb is not enuff .

 

Check Bomb Jack

[emkay]

When he says "Digi music" that doesn't necessarily mean a digitised tune.

 

Just a couple of instrument like drum/symbol samples will be reasonably cheap.

 

 

Yes. And we only need very low sample rates for Drum & base sounds. Higher sounds will be managed via Hardsynth routines.

[Creature XL]

I give you the Gr.7 thing. We can see in Zybex that a lot of soft-sprites are possible.

However, in Zybex they are in front of COLBK (AFAIK) and, personally, I don't like the "blocky" res. But if the game is fast paced it wouldn't matter, i guess.

 

@BombJack, can you tell me what version you are talking about? I have just loaded the version I have (256k) and I can't here any digi sounds. If there are digi sounds I can't distinguish them

Maybe the snare in the title screen?

[emkay]

I give you the Gr.7 thing. We can see in Zybex that a lot of soft-sprites are possible.

However, in Zybex they are in front of COLBK (AFAIK) and, personally, I don't like the "blocky" res. But if the game is fast paced it wouldn't matter, i guess.

 

 

When animations are correct and colours got where they belong to, you may never want another mode anymore

 

 

 

 

@BombJack, can you tell me what version you are talking about? I have just loaded the version I have (256k) and I can't here any digi sounds. If there are digi sounds I can't distinguish them

Maybe the snare in the title screen?

 

 

Man.....

 

Look at the complex graphics, and movement is fine.... even in single scanline mode plus PM overlays. That's what you have to look at. It's done with preshifted objects.

 

Zybex is a crap program , not worth the hassle. Too much bugs are in the game. It was done to load faster from Tape and in no way optimised.

 

 

 

It's a fact that the A8 in some ranges has no ground to work on for fast and good looking games.

Colour mode with PM overlay only works with preshifted graphics.

We have 2 choices to have good looking and playable games:

 

1. Hires in 32 byte width.

 

Hires means too have very small moving objects, so we can move the double of them, compared to colour mode.

 

2. Gr. 7 fullscreen

 

Antic spares DMA and copies every second line without any extra CPU cost. It allows for up to 3 times more moving objects. And it allows the usage of VCOUNT or POKEY's counters, even in fullscreen, because still every 2nd scanline is free from DMA.

 

You know, Sheddy is not doing the impossible with Space Harrier. But he's the only one who treads it all right.

 

 

I still wonder what happened , if some game like Axelay had approached the A8 in gr. 7. Even a 2D shooter with 3D FX would have been possible.

Edited April 15, 2011 by emkay

[Creature XL]

 

@BombJack, can you tell me what version you are talking about? I have just loaded the version I have (256k) and I can't here any digi sounds. If there are digi sounds I can't distinguish them

Maybe the snare in the title screen?

 

 

Man.....

 

Look at the complex graphics, and movement is fine.... even in single scanline mode plus PM overlays. That's what you have to look at. It's done with preshifted objects.

 

Ok, my fault. It sounded like BombJack has digi sounds. You do not have to tell me anything about pre-shifted sprites though

I know a fair bit of A8 coding (although still learning more ). The thing is, it takes a lot longer actually coding up the stuff then just writing about it.

Jose is doing a good job. His non-coder-thinking combined with strong motivation helps me a lot. Although there is the same problem: What is one sentence in a PM for him is 4 weeks of work for me

 

 

Oh at Bomback again: The movement is not so smooth. Of course the reason is to move them slower, however, this fact COULD be used to render the sprites every other frame. At least that was an idea I had for a current project

[MaPa]

Antic spares DMA and copies every second line without any extra CPU cost. It allows for up to 3 times more moving objects. And it allows the usage of VCOUNT or POKEY's counters, even in fullscreen, because still every 2nd scanline is free from DMA.

 

Gr.7 will earn you just about 4000 CPU cycles, so WTF 3 times more moving objects? So you think Atari is moving everything in around 1500 CPU cycles and the rest, roughly little over 20.000 cycles just plays chess with itself?

Edited April 16, 2011 by MaPa

[emkay]

Antic spares DMA and copies every second line without any extra CPU cost. It allows for up to 3 times more moving objects. And it allows the usage of VCOUNT or POKEY's counters, even in fullscreen, because still every 2nd scanline is free from DMA.

 

Gr.7 will earn you just about 4000 CPU cycles, so WTF 3 times more moving objects? So you think Atari is moving everything in around 1500 CPU cycles and the rest, roughly little over 20.000 cycles just plays chess with itself?

 

What Antic does:

 

Let's imagine

fullscreen Gr. 7.

 

Just copying a scanline of 48 bytes takes about 240 cycles. Doing this for 120 lines virtually means 28800 CPU cycles saved, but the screen is fully used.

 

 

 

 

Btw: Gyruss is THE example of a good gr. 7 usage....

[emkay]

Looking backwards, it all makes sense.

 

We just have to imagine -when - the A8 was developed. Everything was experimental. But there was this "graphical door" . And wasn't Starraiders done in 2 line mode?

 

Even VCOUNT works every 2nd line, and POKEY's counters can work better then.

Together with double lined PMs, the usage of screen memory is the half, saving RAM for code or data.

It's still there... reduce the graphics vertically to the half, and get rather more additional features.

 

I'd bet that Turrican in such resolution would also work well.... looking (and what's more important: playing) like the Amigaversion, just with the half resolution in hor. and vert.

 

 

I'd have no problems , if games looked like his :

 

 

[José Pereira]

Looking backwards, it all makes sense.

 

We just have to imagine -when - the A8 was developed. Everything was experimental. But there was this "graphical door" . And wasn't Starraiders done in 2 line mode?

 

Even VCOUNT works every 2nd line, and POKEY's counters can work better then.

Together with double lined PMs, the usage of screen memory is the half, saving RAM for code or data.

It's still there... reduce the graphics vertically to the half, and get rather more additional features.

 

I'd bet that Turrican in such resolution would also work well.... looking (and what's more important: playing) like the Amigaversion, just with the half resolution in hor. and vert.

 

 

I'd have no problems , if games looked like his :

 

 

 

Hi.

Emkay, something around this:

And now?

Any ideas?

(STATUS AREA normal Antic4 in 40wide Mode)

 

 

José Pereira.

 

 

(P.s.- Popmilo just saw you here, if you saw this ...)

[emkay]

Looking backwards, it all makes sense.

 

We just have to imagine -when - the A8 was developed. Everything was experimental. But there was this "graphical door" . And wasn't Starraiders done in 2 line mode?

 

Even VCOUNT works every 2nd line, and POKEY's counters can work better then.

Together with double lined PMs, the usage of screen memory is the half, saving RAM for code or data.

It's still there... reduce the graphics vertically to the half, and get rather more additional features.

 

I'd bet that Turrican in such resolution would also work well.... looking (and what's more important: playing) like the Amigaversion, just with the half resolution in hor. and vert.

 

 

I'd have no problems , if games looked like his :

 

 

 

Hi.

Emkay, something around this:

And now?

Any ideas?

(STATUS AREA normal Antic4 in 40wide Mode)

 

 

José Pereira.

 

 

(P.s.- Popmilo just saw you here, if you saw this ...)

 

Is that a mockup by the same guy who made all the "1000" of coloured gamescreens?

 

 

 

Ofcourse we have to change the graphics size. That's what I proposed more than once in this thread.

Then... again: With this 2 line modes , it is possible to use VCOUNT and/or POKEY's counters in a stable correlation.

[José Pereira]

Looking backwards, it all makes sense.

 

We just have to imagine -when - the A8 was developed. Everything was experimental. But there was this "graphical door" . And wasn't Starraiders done in 2 line mode?

 

Even VCOUNT works every 2nd line, and POKEY's counters can work better then.

Together with double lined PMs, the usage of screen memory is the half, saving RAM for code or data.

It's still there... reduce the graphics vertically to the half, and get rather more additional features.

 

I'd bet that Turrican in such resolution would also work well.... looking (and what's more important: playing) like the Amigaversion, just with the half resolution in hor. and vert.

 

 

I'd have no problems , if games looked like his :

 

 

 

Hi.

Emkay, something around this:

And now?

Any ideas?

(STATUS AREA normal Antic4 in 40wide Mode)

 

 

José Pereira.

 

 

(P.s.- Popmilo just saw you here, if you saw this ...)

 

Is that a mockup by the same guy who made all the "1000" of coloured gamescreens?

 

 

 

Ofcourse we have to change the graphics size. That's what I proposed more than once in this thread.

Then... again: With this 2 line modes , it is possible to use VCOUNT and/or POKEY's counters in a stable correlation.

 

Yes, it is...

But, because it's a Topic started by you, I would like to first ear your opinion...

 

Maybe this from Gameboy was something I already had coloured many, many Months ago, but on ANTIC4.

But probably it also could be coloured in GR.7...

 

 

 

José Pereira

[José Pereira]

 

Guess what is this?

 

GROUND: PFs.

TOWERS (and other Things): P2&P3

OUR GUY: 5th Player as PF3-White/PFO-Darkest Gray(Black)/PF1-Light Gray

ENEMY1: P0/Ored PF0/Ored PF1

ENEMY2: P1/Ored PF0/Ored PF1

SHOOTING: PF0-Darkest Gray/PF1-Light Gray (that horizontal Lines)

 

USE PRIOR0 and MULTIPLEX Enemys (two by Line possible. More Flicker?)

 

Re-design all Gameboy's Gfxs.? Probably

But it will look cool? Probably

It could be coded? Probably

Will I find a coder?

José Pereira.

Edited April 18, 2011 by José Pereira

[popmilo]

...

(P.s.- Popmilo just saw you here, if you saw this ...)

Yeah, I remember this

 

I also like 160x100 resolution + PMs for coloring.

 

Shame, there are only 5 players for a line...

 

But.... still... No reason why it shouldn't be done

 

@Emkay - wouldn't that precise timer timing be influenced by hardware scroll ?

I guess it would be "stable" at least during one frame ?

Only the differences between frames should be taken into consideration when interrupts.

[emkay]

@Emkay - wouldn't that precise timer timing be influenced by hardware scroll ?

I guess it would be "stable" at least during one frame ?

Only the differences between frames should be taken into consideration when interrupts.

 

 

When using the timers for digitised sounds, you will not recognize any interference.

colours and PM positions should be set always via DLIs...

 

Particular Turrican makes many things easier, because it is a trigger based game. Every enemy only appears after the hero has entered a dedicated position.

When huge monsters arrive, there is no scrolling going on... just some shaking.... but what's easier for Antic, than to do some shaking of the screen

[popmilo]

When using the timers for digitised sounds, you will not recognize any interference.

colours and PM positions should be set always via DLIs...

Agreed. I thought you ment some kind of use of timers for graphics stuff. Sound is ok with little irregularities like that.

 

Particular Turrican makes many things easier, because it is a trigger based game. Every enemy only appears after the hero has entered a dedicated position.

When huge monsters arrive, there is no scrolling going on... just some shaking.... but what's easier for Antic, than to do some shaking of the screen

Thats what I considered to be one of small number of flaws in C64-turrican. You could avoid whole bunch of enemies by simply running towards place where they appear and then just running back a little and when you come back they are gone...

I know its because of memory and cpu needed to track so many objects at once... But I would like to "correct" it somehow

 

"Metal warrior" on C64 did "proper" consistent-object-actor type of entities. That is type of thing I would aim for.

 

Anyway... plenty ways to optimize if you have rough thing working first.

[emkay]

Forgot the "best" example of the "new age" . Ofcourse Yoomp!

 

No other game seems to make this much use of animating screen content. Here Gr. 7 made a game possible, no one would have dreamed of : An Ego-View Tunnel built with 3D looking tiles running on a stock machine, fluent....

[emkay]

Some variations, just like a fixed "violin sweep" on the main instrument, and some bass with a better "rhythm" ...and some reverb here and there...

 

 

 

ttf.xex