62 replies to this topic

[Sikor]

I thinked about game like "Space Ace" or "Dragons Lair". It is possible make it on little Atari's? Maybe...
O.K. Some facts: original game has many, many animation - it is hard to make it all on our computer (hmm, maybe on KMKIDE interface?), but... What will be, when we use only few from each scene? I don't know assembler language, only Turbo Basic XL. What will be, when we prepare some GFX? Al scene must be in memory, but every scene can be loaded one after one - as in original game...
O.K. Some mathematics: when we use assembler we can use about 40KB max for gfx (in some place must be code). 40x1024=40960 bytes. In GR15 mode we has 7680 bytes per screen. Match again: 40960/7680=5,333... Too short... But, when we use GR7 mode for game - we can double this... It's about 10 screens for scene. Not bad, I think. 10 without compression, of course.
O.K. We can (supposedly) use 10 screens for scene. Hmm, 10 screens (without compression) give us 38400 bytes (it is 37,5KB). What next step...? I think, that 16MB ATR will be o.k. (it is more than 400 scenes). So, it is good point to use it. But, what with GFX? From ST, Amiga, VGA? Its has to many details to good conversion, so? I find info on mobygames, that SA had made on CGA card too. All gfx is in small pallette. I try to convert it. And, finally - You can see screenshots above this text. You can see some example: original CGA pic, and pic on Atari - in static scene I used GR15 mode. For example in scene I used GR15 mode, GR7 mode and converted GR15toGR7 mode (for seeing differences).
Now, it is only concept. Examples You can see on attached SAC.XEX file. I'm not real programmers, but - if it is any - maybe someone can made it? I can help with GFX convert - but I haven't original pic.
What do You think about it?
(sorry for my english...)

Attached Files

•  SAC.XEX   33.7K   76 downloads

[emkay]

The question is not, if the game can be done for the A8.
The question is, if someone is doing it.

Some things seem never to reach the A8. Just like a good Music Tracker , or a real DMA Harddisk Controller.... and some other essential development tools....

[tdc]

Pirx was made nice algorythm to real-time decompresing animation like this. Maybe He is going to make this game - I hope!

Edited by tdc, Sat Sep 10, 2011 2:58 PM.

[Armonigann]

I thought no... until I saw pics.

[therealbountybob]

You're english is good sikor
perhaps you could describe the gameplay a bit as it's not clear what sort of game it is from the screenshots ?

[GroovyBee]

therealbountybob, on Sun Sep 11, 2011 5:23 AM, said:

perhaps you could describe the gameplay a bit as it's not clear what sort of game it is from the screenshots ?

[Synthpopalooza]

Ideas:

Adding DLI's and PM overlays to the graphics can increase colors.

Use G2F to make font pictures. That way you can not only save memory, but also gain access to the Antic 4 (or 5) fifth color.

Maybe make this on a 130XE and use the extra 64K ram to store images.

[Sikor]

@Synthpopalooza: you're right. But I don't know how use it in Turbo Basic XL...
O.K. I tried: scene 1 has about 23 differen pictures. In Turbo Basic I can use about 7 at one moment (maybe next weekend I'll do some examples)in GR7 mode (without compression). In assembler - its about 10-11, it is anought. Because most of them has only minor changes - I think, that all of it can be used.
P.S.==> Scene 1 you can see on ones from pictures in post #1

[Synthpopalooza]

Sikor, on Sun Sep 11, 2011 8:04 AM, said:

@Synthpopalooza: you're right. But I don't know how use it in Turbo Basic XL...
O.K. I tried: scene 1 has about 23 differen pictures. In Turbo Basic I can use about 7 at one moment (maybe next weekend I'll do some examples)in GR7 mode (without compression). In assembler - its about 10-11, it is anought. Because most of them has only minor changes - I think, that all of it can be used.
P.S.==> Scene 1 you can see on ones from pictures in post #1

Well, if I can do up some font pictures from your PNG's, I have a nice table DLI routine in BASIC which works well in text mode (got it out of Compute! magazine I think) that does a table change on two registers anywhere on the screen. I can set it to change one of the color registers, and the character set. I may try to work on that tomorrow

Edited by Synthpopalooza, Mon Sep 12, 2011 8:16 AM.

[Wrathchild]

Would it be easier to 'stream' this from the device (I'm assuming that this would be IDE based) in the same way Mr Atari's videos were done, as experiments have been done with 'colour' playback? The engine behind the Dragon's Lair games (certainly on the PC) have a tiny script that is basically just waiting for a point in playback to allow the user to push the joystick in a direction or press the button and then that determines the next sequence to play and then that sequence could be linked to 'death' after playback. This way the original audio could be re-sampled and used.

Trying to code up the screens in terms of animating sprites/chars over backgrounds seems like a lot of work? (granted the resolution maybe worse in a streamed solution but the motion going on may cover over some of that)

Mark

Edited by Wrathchild, Mon Sep 12, 2011 9:48 AM.

[Bryan]

I think Sheddy's trick of double palettes would work well here, especially if interlaced. Scan the screen into 7 colors (PF0-2, PF0-2, BAK) and choose the palette based on the prevailing colors of the current scene.

[Sikor]

O.K. Quick preview (with no timing and no color optimazed) opening scene 1 in GR7 mode. It is 9 pics from 23 original. No compress, only Turbo Basic XL rountines. Remember: color and timing is not set yet. It is only quick preview. Maybe at weekend I'll find some times to make more effective this one.

Attached Files

•  SASC1.XEX   44.48K   66 downloads

[Sikor]

Next my 5 cents. I have not programs to good grabe pictures from DOS Box. Virtual Dub is O.K., but - unfortunately - i must grab under vista all desktop and cut gfx manually. Maybe it is any solution to grab clear gfx from DOSBOX? If i'll get clear 320x200 pics from it - it will be best method to quick and good convert it from PC to Atari?

[Sikor]

Hmm, maybe it will be possible use gfx from Atari ST? Quick screenshots: ST, GR15, GR7. Next tests for few days... Color not set correctly yet on little Atari, but we can see, how it look on our machines...
===>edit: hmm, if we use GR9 mode with every second scanline empty we get more than good effect... Maybe, if we use modified DL we use this mode... Question is: how modify DL of GR9 mode to quickly use 4KB data in Turbo Basic. With this trick we can get as same PICs as in GR7 mode, but with more details (less pixels but more shadows). What do You think?

Edited by Sikor, Tue Sep 13, 2011 3:31 PM.

[Synthpopalooza]

Sikor, on Tue Sep 13, 2011 3:17 PM, said:

testst.png zst_gr15.png zst_gr7.png zst_gr9_in.png
Hmm, maybe it will be possible use gfx from Atari ST? Quick screenshots: ST, GR15, GR7. Next tests for few days... Color not set correctly yet on little Atari, but we can see, how it look on our machines...
===>edit: hmm, if we use GR9 mode with every second scanline empty we get more than good effect... Maybe, if we use modified DL we use this mode... Question is: how modify DL of GR9 mode to quickly use 4KB data in Turbo Basic. With this trick we can get as same PICs as in GR7 mode, but with more details (less pixels but more shadows). What do You think?

I know of two methods to do this:

First method is a call to Graphics 9 and have a LMS (Load memory scan) on every 2nd line of your display list which repeats the data in the above line ...

Say, you have your first line, then the second line has a load memory scan to the address of the top line, in this fashion you are essentially repeating the first line twice, and halving the resolution. So, your display list might be something like this:

112 112 112 (three sets of 8 blank scan lines)

79 (graphics 8 load memory scan)
next two bytes are your screen address, screen location of where your scanline starts. You can determine this from DPEEK(88) or PEEK(88) and PEEK(89)

79 followed by the same two bytes

Then repeat these instructions 96 times:

15 (graphics 8 )
79 followed by the screen location of the above line 15 (you add 40 to your screen location every time)

After that, do these instructions:

65 (Jump and wait for VBLANK) followed by the address of your display list (two bytes) which you can usually find by PEEK(560) and PEEK(561)

Keep in mind, in Graphics 9, you are using a Graphics 8 display list, so you have to use 15's and 79's.

This method uses only 4K of screen memory. It might even do for you to do a Gr. 7 call and then load in your display list as described above, and do a POKE 623,64 to set the screen into mode 9 so that your screen memory remains at 4K.



Method #2: Another way to do this, although you will lose color data, is to do a call to Gr. 7 and then POKE 623,64. Tradeoff of this method is, you only get 9 level shading in this mode, and I believe these colors are available (in this order): 0 0 1 2 0 0 1 2 4 4 5 6 8 8 9 10. I think the old Compute magazine article called this Graphics 7.9. So lower color resolution but it is easier to set up than the above method.

For converting jpg and gif to atari formats, I have found that Graph2Font works well ... there is another program on the Atari by Jeff Potter called APACView which can convert GIFs to APAC mode, and it also does Pryzm mode (256 color 80x192 VBI) plus you can save a Graphics 9 luminance mask of the picture.

There are more advanced techniques which require display list interrupts ... like alternating mode 9 and 10 every scanline and setting the mode 10 colors to monochrome, this will get you an illusory 160 pixel across resolution because the mode 10 pixels get shifted 1/2 to the right. Or putting Graphics 15 every second line from Graphics 9 and using monochrome for mode 15. Or doing the pictures in APAC mode (80x96 256 colors which would require a blank scan line every 2 lines).

Just in case, I'm going to post you the ATR for the May 1988 issue of Analog which has the APAC graphics mode which you can use in BASIC.

http://ftp.pigwa.net...ALOG/88_MAY.ATR

Grab that and look for the APAC demo on that disk. Might come in handy.

Edited by Synthpopalooza, Tue Sep 13, 2011 4:24 PM.

[Synthpopalooza]

Here's Jeff Potter's APACView ... it will make apac mode pictures, and also allow you to make Graphics 9 or 11 pics from gif files.

 ApacView v2.4 (1992-10)(Jeff Potter).atr   90.02K   34 downloads

[Sikor]

At weekend I'll try thinking about it. For now only 4KB/pic is max, so interlaced modes are too big...

[carmel_andrews]

Perhaps if one of our euro codeheads can do some sort of ASPI type driver that allows you to use CD/DVD drives or even old school laser disks with the A8, then I think it might be possible

Since i do recall, that coleco had some sort of deal with The Coin op company that did Space Ace and coleco got a laser disk version for it's gaming system, Microdeal did a similar thing for the Atari ST, in combining the Coin op Disk with ST hardware

[analmux]

carmel_andrews, on Thu Sep 15, 2011 8:09 AM, said:

Perhaps if one of our euro codeheads can do some sort of ASPI type driver that allows you to use CD/DVD drives or even old school laser disks with the A8, then I think it might be possible...

Then as well a blitter/GED-kernel is possible, for a lot more onscreen colours. That's because the disk IO DMA will do the main work needed. Combining this with the GPRIOR0 setting: many interesting colourful stuff should be possible.

[Sikor]

O.K. Today I add speed test of running opening scene one converted from ST. Now colors are strange - i must find good algorithm to convert color from ST to little Atari for best result (I must automatize it for fast converting). On some emulators it looks strange, on my little Atari and on Atari800Win it looks acceptable (with minor changes of color palette - look at screenshot). Now its run with nearlu full speed (no optimazing time) - so, I think, it's really to make SA type game on little machines like our Atari.
O.K. I try next few days made some better pictures and color optimaze for this try.

Attached Files

•  SA1SC1.XEX   44.11K   43 downloads

[Sikor]

O.K. Next step - now color is set to probably best result to standard Atari graphics (thx Miker to help). Can You reply - is it acceptable for You?
For next few days maybe we'll do some more details for this scene - now, all is on test yet.
This attachment is in standard GR7 mode, slowrun this time, with color sets. I wait for reply - is that collors are acceptable for peoples? Welcome testers on real machines.

Attached Files

•  SA1ST.XEX   44.42K   43 downloads

[Sikor]

O.K. One more for the incentive - death scene from 1st part. It's one problem, which I saw: on every scene color must be set separately... But it is simple to do

Attached Files

•  DS1ST.XEX   40.36K   51 downloads

[Synthpopalooza]

Ok thought you might find this interesting:

I did a Space Ace title screen using Super IRG 2 (23 colors at Antic 4 resolution).

I created this using G2F and making two seperate font files with two sets of color information, and an SCR file

I can only display 16 lines of character using this, but I'd like to see what you think.

run "d:spaceace.tur" from the atr




 spaceace.atr   90.02K   39 downloads

[Stephen]

Synthpopalooza, on Sat Oct 8, 2011 12:23 PM, said:

Ok thought you might find this interesting:

I did a Space Ace title screen using Super IRG 2 (23 colors at Antic 4 resolution).

I created this using G2F and making two seperate font files with two sets of color information, and an SCR file

I can only display 16 lines of character using this, but I'd like to see what you think.

run "d:spaceace.tur" from the atr


spaceace-superirg2.png

spaceace.atr

Looks really nice.

[emkay]

I'd propose to use interlace for the game.
As soon as things move on the screen, interlace isn't that bad, the gained colours would be worth it.
Fixed images would do better without interlace.

How about GR. 7 interlaced for ingame?