Jump to content
IGNORED

Space Harrier XE


Recommended Posts

[Let's have a look on my prefered picture (using 6 colors):

 

The colors are made by:

 

708 -> black

709 -> yellow

710 -> grey

711 -> orange

712 -> red

 

704-707   -> green (made by PMg behind the playfield)

 

712 is the Background

710 & 711 can be switched by character invert ( higher than 127)  

708-711 filters the resolution of the PMg.

 

 

red, blue and grey are made by using PMg

violett is made by font inversion

The picture uses 8 colors

 

do you get it now?

 

Okay, but according to the screenshots these pictures don't seem to be mixing any new colors. They use the colors in the palettes, some dithering, and the players to alter the background colors in places. Where does the undetectable color mixing (GTIA 'bug') come into play?

 

-Bry

Link to comment
Share on other sites

Okay, but according to the screenshots these pictures don't seem to be mixing any new colors. They use the colors in the palettes, some dithering, and the players to alter the background colors in places. Where does the undetectable color mixing (GTIA 'bug') come into play?

 

 

I made/converted this pictures a long time ago and didn't get any advantage to the technique. So you have only the "real" colors available.

 

Maybe this will help out:

 

download.php?id=1818

 

Take a look at the "Spieler" Scoreboard. I used a displaylist with changing mode e/f/e/f etc.

So the colors are made by ANTIC e and for the "hires" ANTIC F is used.

Please take care about the color in hires is depending on the background. It is black, so the resulting color is grey.

By changing of blue/grey/blue/grey etc. here I got a "hires" color font. Please compare the "0000" with the original colorfont "INFO".

 

 

 

BTW: Take a look at the pointers ... they are hires with two colors....by the same way .

Link to comment
Share on other sites

Can you post the pic as a .gif or .tiff emkay? ...We can't see the details of the clever stuff you've done because of the jpeg artifacting  :D  

 

Thanks

 

It is not neccesary. The picture has the detail you need to view the effect.

 

Perhaps... how it is done, you may see on the Emulator...

 

The picture is a snapshot of my XL via a PC framegrabber card. On a monitor it will not be any sharper.

Link to comment
Share on other sites

So "Chronocolour interleaved " = ColorView?

Yep, same technique. There are quite a few still images he's done that you can download. Considering the low resolution of the 2600 and that it can only generate 8 colors this way, the results are surprisingly good.

 

Whole thing got started in this thread (just skip over page 4).

Link to comment
Share on other sites

emkay... this is a technical milestone... but to be little bit provocative (?)... does the game benefit from the tec stuff/screendesign you have invented?

 

imho not... so all afford you have put into this one screen (in technical meaning) is from my point of view far beyond what would be necessary to get the same impression by the target audience... as nobody from the general public will realise how much hard work it was... ;)

 

that's why i do not code anymore but give design input... as done with numen... ;)

 

i had tons of source code with "weird" effects which my TQA guys kicked as it's not good looking enough... doesn't matter how good it was coded... :)

 

but please don't take this personal... your technique could be used smart & clever on status bars etc... but i don't see this CPU consuming (i might be wrong...) tricks usable in a game...(except title screen f.e.)

 

same goes with MCS and all other multicolor tricks... for games... i don't see that... as f.e. space harrier you would need to manipulate antic e + the player/missle area so at least double amount of data... and in combination with DLIs your engine gots slower and slower...

 

but i see your stuff for strategic games, etc... but not for more?

 

hve

Link to comment
Share on other sites

i had tons of source code with "weird" effects which my TQA guys kicked as it's not good looking enough... doesn't matter how good it was coded... :)

 

What a waste of routines - put them all together and release for gawds sake, there's no point in leaving them to rot! =-)

 

but please don't take this personal... your technique could be used smart & clever on status bars etc... but i don't see this CPU consuming (i might be wrong...) tricks usable in a game...(except title screen f.e.)

 

i s'pose they're good for puzzle games...

Link to comment
Share on other sites

Heaven wrote:

 

>emkay... this is a technical milestone... but to be little bit provocative (?)... does the game benefit from the tec stuff/screendesign you have invented?

 

Ofcourse it does. It fits more to the eyes of People outside the ATARI-world than other games are still doing. It has color it has style and it was very much fun to do this. Only by doing development in this way, the 8-bits would have lived many years longer on the commercial market.

 

>same goes with MCS and all other multicolor tricks... for games... i don't see that... as f.e. space harrier you would need to manipulate antic e + the player/missle area so at least double amount of data... and in combination with DLIs your engine gots slower and slower...

 

Games like Space Harrier are better done the way Sheddy does. But Sheddy does waste much CPU Time by his routines, that are a real 3D-Engine.... a very fast imho ;).... this could be done by tricking (like on C64) very much faster.

 

 

With the MCS as a rudimentary standard, you may just enhance it by DLI and using of scrolling with multiplexed players.... and a spriteroutine that fits to the non-linear fontscreen.

MCS was thought as a standard to make C64 conversions.

May I suggest you: It is a harder way to create something new, than to remake anything.

MCS and the ADMIRANDUS-Screen ( including some development tools) is built by my own. Only some graphics are used that were available this time by public domain...

How much People are TaQuart? How long does it take for a Demo?

Please note, if I had found some good Programmers in ~1991 the Software I wanted to do was at hand today. Including "The Last Ninja" and "Turrican". But the Games had to be there in 1992 and not today ...

 

And BTW: My Job has nothing to do with programming, graphic- or soundcreation and I didn't know people in personal who are able to do this in profession... So it was hard, but it was fun :)

And due to my fulltime Job I had to do , and the "walls" I was talking to I gave up all Softwaredevelopment on the XL/XE.

 

At last: 1988 I asked a programmer in ABBUC to create programs like RMT to create sounds like in "slow" and 2003 Raster made it possible....

And now I am asking myself: Why is that all so slow after all? At the current development-speed Turrican will be available in approximate 200 years ;)

Link to comment
Share on other sites

I made/converted this pictures a long time ago and didn't get any advantage to the technique. So you have only the "real" colors available.

 

Maybe this will help out:

 

Take a look at the "Spieler" Scoreboard. I used a displaylist with changing mode e/f/e/f etc.

So the colors are made by ANTIC e and for the "hires" ANTIC F is used.

Please take care about the color in hires is depending on the background. It is black, so the resulting color is grey.  

By changing of blue/grey/blue/grey etc. here I got a "hires" color font. Please compare the "0000" with the original colorfont "INFO".  

 

Can you post the Spieler binary?

 

-Bry

Link to comment
Share on other sites

@Sheddy

 

How much DLIs/colorchanges are you doing in Space Harrier ?

 

Only one colour gets changed on each DLI. The amount of DLI's varies from stage to stage. Some of the stages like stage 1 only have about 10 DLI's, stage 3 now has just over 40. What makes you curious???

 

PS regarding 3d engine...I do cheat horribly wherever possible :D Hardly any real 3d calculations are going on. Normally the "scenery" (things on the ground like trees, bushes etc. and rocks in the air) have one division calculation on their x position. y position is all table driven. Nearly all the aliens run in 2d, only some bosses have 3d when I can't fiddle it in 2d to look right :wink:

Link to comment
Share on other sites

Only one colour gets changed on each DLI. The amount of DLI's varies from stage to stage. Some of the stages like stage 1 only have about 10 DLI's, stage 3 now has just over 40. What makes you curious???

 

 

How much does it influence the speed of the game between 10 and 40 DLIs?

With approximatly 40 DLIs it would be possible to multiplex PMs .... maybe .... to create Jump and Run Game platforms for the "Hero"(*) to stand above.

 

* The Hero could be made by a character-based Softwaresprite :ponder:

Link to comment
Share on other sites

 

How much does it influence the speed of the game between 10 and 40 DLIs?

With approximatly 40 DLIs it would be possible to multiplex PMs  .... maybe ....  to create  Jump and Run Game platforms for the "Hero"(*) to stand above.

 

* The Hero could be made by a character-based Softwaresprite  :ponder:

 

OK - that could be fun! Why don't you have a go, and post a proof of concept in the programming forum?

 

The DLIS do affect the speed a fair bit. Here follows a rough calculation:

 

Approx cycle count per NTSC frame = 1,790,000 / 60 = 29833

cycle count per DLI (assuming a WSYNC) = 114

cycles for 40 DLIS = 114 * 40 = 4560

 

4560/29833 = 0.153 or about 15% of the total processor time if I did the math right :sad:

 

That doesn't factor in any DMA fetches though

Link to comment
Share on other sites

 

The DLIS do affect the speed a fair bit. Here follows a rough calculation:

 

Approx cycle count per NTSC frame = 1,790,000 / 60 = 29833

cycle count per DLI (assuming a WSYNC) = 114

cycles for 40 DLIS = 114 * 40 = 4560

 

4560/29833 = 0.153 or about 15% of the total processor time if I did the math right :sad:  

 

That doesn't factor in any DMA fetches though

 

Did you made tests about colorchanging in one Scanline?

 

a simple 'lda 0 sta col lda a sta col ' shows a longer color line at the beginning of a scanline. The more the scanline goes to the end of the scanline, the shorter is the color-line....

This means, that the DMA of the ANTIC acts more at the beginning of a scanline as at the end...

 

For a programmer this means : Use the DLI not only to change one color ;) Too much CPU Time will be wasted.

 

The only good thing is: while WSYNC happens the DMA happens partial too. So you don't lose ANTIC DMA & DLI-Time in full addition

 

Depending on yours, let's make a simple calculation too ;)

 

In fullscreen ANTIC DMA cost 30% of CPU Time.

A full DLI uses 114 cycles

 

114cycles -30% =79,8 cycles

 

So 79,8 cycles of available cycles for the program are used for the DLI including WSYNC.

Depending on the used Mode, the resulting cycles are more or less.

 

You may correct me if I am totally wrong ;)

Link to comment
Share on other sites

Actually emkay, I think we may both be wrong!

 

I think the 114 cycles per scan-line already allows for DMA? Maybe someone else can confirm that, without us having to plough through the hardware manual?

 

reasoning as follows:

 

the Atari is designed to do one clock cycle per colour clock. There are 160 colour clocks in a normal size screen. The most Antic can fetch is 40 bytes every line :sad: (normal mode), and Player/Missiles have to fetch 5 bytes.

 

160 - 40 - 5 = 115, is darn near 114. Surely that can't just be a coincidence?

 

Ah, I forgot the Display list also has to be included. Once that is set up for normal screens it will take only 1 byte per line.

 

If that's right, I think the figure of 15% of stolen cycles is fairly accurate.

 

Just to confuse things further - memory refresh also has to happen, but I don't remember how many cycles it steals - I'm sure it's more than just 1 per scan-line though!

 

I've also tried to think what useful work could be done instead of waiting for WSYNC - but I've not come up with anything useful, except more colour changes, etc. EG Time slicing code has too much overhead :P

Link to comment
Share on other sites

Sheddy wrote:

 

Actually emkay, I think we may both be wrong!

 

I think there is something more wrong about the calculation belonging to ANTIC and his CPU-Time stealing....

But I think, I am right in my thoughts....When ANTIC DMA is enhanced by Hi-Res or 5-color charmode and hires PMg , the time that is truely lost by WSYNC is less than by using a mode of lower resolution....

.... I hope it is possible to follow my logic ;)

Link to comment
Share on other sites

Actually emkay, I think we may both be wrong!

 

I think the 114 cycles per scan-line already allows for DMA? Maybe someone else can confirm that, without us having to plough through the hardware manual?

 

reasoning as follows:

 

the Atari is designed to do one clock cycle per colour clock. There are 160 colour clocks in a normal size screen. The most Antic can fetch is 40 bytes every line  :sad: (normal mode), and Player/Missiles have to fetch 5 bytes.

 

160 - 40 - 5 = 115, is darn near 114. Surely that can't just be a coincidence?

 

Ah, I forgot the Display list also has to be included. Once that is set up for normal screens it will take only 1 byte per line.

 

If that's right, I think the figure of 15% of stolen cycles is fairly accurate.

 

Just to confuse things further - memory refresh also has to happen, but I don't remember how many cycles it steals - I'm sure it's more than just 1 per scan-line though!

 

I've also tried to think what useful work could be done instead of waiting for WSYNC - but I've not come up with anything useful, except more colour changes, etc. EG Time slicing code has too much overhead :P

 

 

There are 228 color clocks per scan line (160 visible in Normal PF). The CPU runs at 1 cycle every 2 color clocks, so you have 114 cycles (228/2)_before_ DMA, which can steal up to 80 consecutive cycles (all of them in the visible area of the screen - 160 color clocks) on the 1st line of a row of text. After the 1st row, the characters are read from Antic's internal buffer.

 

In gr.0, just try changing COLBK after a DLI & a WSYNC (putting you at line 0 of a text row) and moving the change point across the screen with NOP's. You'll notice that it jumps from the left border to the right with just 1 NOP. This is because DMA can consume up to ALL of your cycles in that area (not even RAM refresh happens on this line) leaving you with the 34 cycles in the borders, minus the DL and Player reads.

 

114 total cycles, and 80 of those are in the Playfield and are lost = 34.

of those 80, 40 are used for reading character numbers and are cached, and 40 are used for reading the 1st line of character graphic data.

 

For the next 7 lines of the text, the DMA load is about half of the available time: 40 cycles for reading the 2nd+ line of character graphic data.

 

In a line doubled mode, fortunately, Antic reads the 2nd copy of the line from an internal buffer so it can save you a lot of CPU time.

 

Any mode that displays 160 pixels by 4 colors will steal 40 cycles on the 1st line it is displayed on.

 

Hope this helped...

 

-Bry

Link to comment
Share on other sites

  • 2 weeks later...
a simple 'lda 0 sta col lda a sta col ' shows a longer color line at the beginning of a scanline. The more the scanline goes to the end of the scanline, the shorter is the color-line....  

This means, that the DMA of the ANTIC acts more at the beginning of a scanline as at the end...  

 

 

Oh yeah, the reason Antic steals more cycles at the beginning of a line is because that's when it does the RAM refresh cycles.

 

-Bry

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

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