AGD Atari Game Designer development

[popmilo]

Hello to all interested in making games on Atari 8-bits !

 

Based on information gathered in a game maker poll I'm opening this topic for all stuff related to graphics, music, pc editor, compiler etc.

 

Not much to see right now except for small sprite demo, but will edit this post with new stuff as it gets ready.

 

Simple sprite demo:

agd.xex

Edited November 20, 2015 by popmilo

[popmilo]

Lets begin

 

Today I was thinking of how to make sprite masking without sacrificing lot of RAM.

 

Strange gtia pixel bit values jumped in to help

 

As only 9 colors are useful in gtia mode, that leaves 6 values that can be used for determining which pixels should be transparent.

Even better value %1111 (15) can be used directly as mask.

 

Main code would look like this:

LAX (sprite),y
AND (screen),y
ORA tabspr,x
STA (screen),y

Where tabspr has all %1111 pixel values replaced with %0000 (transparency).

 

I've also decided to sacrifice 5bytes more for each 4bytes row of sprites to avoid shifting and oring bytes as it takes a lot of time.

Will code all this in next couple days and post results. Should be faster and prettier

 

[snicklin]

I'm thinking that your code will need to be very flexible for what you are trying to do.

 

If you tie this into the GTIA mode, what will happen if you decide to do graphics 12 code later? Will you be able to easily adapt to that?

[Kyle22]

Why don't you use only a couple more bytes and make it compatible for everyone?

[popmilo]

I'm thinking that your code will need to be very flexible for what you are trying to do.

 

If you tie this into the GTIA mode, what will happen if you decide to do graphics 12 code later? Will you be able to easily adapt to that?

Why don't you use only a couple more bytes and make it compatible for everyone?

Think of it this way:

1. Start PC gui and choose mode your game will run in (For start there will be only one GTIA 9 color 80x112 mode)

2. Draw your sprites in gfx editor on a large spritesheet (big image with all sprite frames). Editor will be mode sensitive and will allow you to draw sprites with limitations of chosen mode.

3. Write your game code. There will be only couple commands related to sprites (something like DrawSprite and EraseSprite),

4. Build your project and execute it

 

Plan is to reserve large chunk or memory for graphics including display memory, sprite and tile data. Only thing we need to write are display lists and sprite draw routines for that mode.

 

So when first GTIA version is working and there are no serious bugs in script language, gui editor and music code - then we just write editors for Graphics 12, write dlists for character screen, PM multiplexer and maybe soft-sprite routine in char mode. Plug that in that same chunk of memory reserved for graphics earlier.

 

I'm not 100% sure, but my guess is that it will be much easier than getting all this game-maker+gfx+script compiler to work

[Kyle22]

I was referring to LAX (sprite),y which my processor would interpret as a Stack Relative LDA Indirect Indexed,Y.

 

As new devices such as XL14 and Rapidus become more popular, the goal should be to write code that is compatible with all.

 

How about two versions? One for the new processors that uses the new instructions properly, and another version for the old NMOS chips using your Illegal opcodes.

[popmilo]

I was referring to LAX (sprite),y which my processor would interpret as a Stack Relative LDA Indirect Indexed,Y.

 

As new devices such as XL14 and Rapidus become more popular, the goal should be to write code that is compatible with all.

 

How about two versions? One for the new processors that uses the new instructions properly, and another version for the old NMOS chips using your Illegal opcodes.

No problem with that, one more TAX won't matter much for speed. I'm more than happy to make it compatible than to chase some 1% speed improvement.

After all it's not a demo effect with world record as a goal

[Kyle22]

No problem with that, one more TAX won't matter much for speed. I'm more than happy to make it compatible than to chase some 1% speed improvement.

After all it's not a demo effect with world record as a goal

Thanks for understanding, from myself and all the other 802 and 816 users!

[popmilo]

Thanks for understanding, from myself and all the other 802 and 816 users!

After listening to Bill Mensch interview I'm supporting 'clean' code even more.

Funny how he explained it "so called illegal opcodes were codes we didn't use and we didn't care what they do"

So all that cool stuff we like to use in demos to squeeze one more cycle or one more byte is just an accident.

 

I didn't know before listening the interview that he replaced all those unused codes with different timed NOPs in later cpu versions. So I'll stick to clean code as it's much more important for general-purpose software like a game maker to work on multiple cpu's then to be little faster.

 

I'm still going to use lax and sbx in demos for my 800XL of course

[popmilo]

Small update:

 

- Sprites are preshifted (for every row of 4 bytes there is now additional 5 bytes for the same row shifted one pixel to the right).

- Pixel value %1111 is transparent pixel. Sprites are drawn using autogenerated mask so we have 9-color masked sprites.

 

Here is demo of routine with quickly drawn rgb cubes flying around:

Use joystick up and down to change number of sprites.

 

 

agd.xex

 

As currently drawing and erasing sprites is done kind of manually (there is no 'sprite engine' to speak about) next step will be to make sort of sprite list based routine. Plan is to have list of sprites to be drawn for each buffer (sprite ID, x,y). Once buffer goes of screen, erasing routine would go through same list and do it's job.

 

Will have to combine that with background drawing later. Background tiles could be drawn in similar manner and if that turns out to be too slow, sprites will have to restore background instead of simple erasing of previous position.

[+Philsan]

Awesome!

Sprites will have collision registers (with sprites and foreground colors)?

[popmilo]

Awesome!

Sprites will have collision registers (with sprites and foreground colors)?

Thanks

 

I'll probably leave that to coders in the first version. In the later 'user friendly' version there will be events on collision between player, enemies and objects that you can connect to different actions.

[tschak909]

That's some beautiful soft-sprite action. wow.

 

-Thom

[popmilo]

Here's some more soft-sprite action

 

Added one more sprite image and some background to see that masking is really working.

This turned out to be good test of routine speed. "Wall" in the background is redrawn on each buffer change from zero.

What it means is there is nothing smart about it

Pure redraw all objects on screen each animation cycle. For a game coding scenario this is great as you don't have to take care of previous frame, where the sprites were, did sprites go over background or not. Just Erase sprites, draw background and draw sprites.

 

And it's using sprite routine for drawing background wall blocks (with full masking). In next version it will be pure lda-sta routine that should be able to draw much more blocks with same speed.

 

Exe:

agd.xex

 

Enjoy!

 

[Synthpopalooza]

I'm thinking that your code will need to be very flexible for what you are trying to do.

 

If you tie this into the GTIA mode, what will happen if you decide to do graphics 12 code later? Will you be able to easily adapt to that?

 

Adapting to the GTIA 10 9-color mode in Graphics 12/13 is possible, but it requires reorganizing the bit combinations. Basically, you will have 7 bit combinations (7 colors) per character cell (these are pm0 - background, pm1, pm2, pf0, pf1, pf2, and BAK which is graphics 10 color 9). Inversing the character will change PM2 to PM3 and PF2 to PF3 respectively, giving 9 colors. You also have 9 other bit combinations free, but be careful, the last 4 (1100 to 1111) are mapped differently in inverse than in non-inverse characters.

[tschak909]

can we just get these routines in a nice little package on disk that we can fold into our own assembler games? These routines are _REALLY_ good.

 

-Thom

[popmilo]

Adapting to the GTIA 10 9-color mode in Graphics 12/13 is possible, but it requires reorganizing the bit combinations. Basically, you will have 7 bit combinations (7 colors) per character cell (these are pm0 - background, pm1, pm2, pf0, pf1, pf2, and BAK which is graphics 10 color 9). Inversing the character will change PM2 to PM3 and PF2 to PF3 respectively, giving 9 colors. You also have 9 other bit combinations free, but be careful, the last 4 (1100 to 1111) are mapped differently in inverse than in non-inverse characters.

Imho simplicity is much more important than speed right now. "Any pixel any color" is an awesome experience on Atari. Yeah, resolution is not that great but simplicity of sprite routines and everything graphics related is so easy to code that it would be shame to miss it.

 

One of scenarios I can see it potentially working in would be a shooter game where everything is built with chars and moves in character resolution.

Make those 128 chars into cubes, spikes, round corners in different colors and combine them (with inverse mode also for more color) into different shapes for background and stuff you shoot at.

Something like Lumascii on Spectrum:

 

Could work really well and look good. Will experiment with it when I find some time...

[popmilo]

can we just get these routines in a nice little package on disk that we can fold into our own assembler games? These routines are _REALLY_ good.

-Thom

Thanks for kind words, but I would call these routines 'simple'

 

Here are current source files:

agd_source.zip

 

Sprite drawing is in "graphics.asm". Think it uses some tables defined in main "agd.asm", works with two buffers and has a custom Dlist with 256 byte per scanline.

Let me know if it's usable or you need more explanation about how it works.

[Tezz]

Good stuff Vladimir, I hope you'll still continue your own game projects as well as AGD

[tschak909]

These routines could do a _really_ smooth Pengo.. hm..

[popmilo]

These routines could do a _really_ smooth Pengo.. hm..

If you can draw or steal some Penguin sprites I can make a demo

 

ps. That type of game would be a good candidate for testing scripting language and complete engine.

[popmilo]

Good stuff Vladimir, I hope you'll still continue your own game projects as well as AGD

There are two-three more in the process all the time, just hope that coming winter and baby getting older is going to mean more time for coding

[tschak909]

What did you use for the sprites you have? If I have to use graph paper, then fine.

 

-Thom

[popmilo]

What did you use for the sprites you have? If I have to use graph paper, then fine.

 

-Thom

Well, as you can see in this table that is used to get 'x coord' (in bytes) of sprite in a big chunk of memory reserved for sprite images:

tab_mult_9_plus_offset
:19             DTA [#*9]+(SCREEN_WIDTH*2)

Sprite images are located in a space right from two screen buffers:

 

So, I used paper and pen

And wrote this based on that. Change these values and you can draw any sprite you want.

First 9 bytes are sprte 0 (Cube) and next 9 bytes are Wall.

sprite_shapes
;RGB cube sprite                                        WALL SPRITE
                DTA $FF,$F0,$FF,$FF,$FF,$FF,$0F,$FF,$FF,$00,$00,$00,$00,$F0,$00,$00,$00,$0F
                DTA $FF,$02,$0F,$FF,$FF,$F0,$20,$FF,$FF,$08,$88,$38,$32,$F0,$88,$83,$83,$2F
                DTA $F0,$33,$20,$FF,$FF,$03,$32,$0F,$FF,$08,$33,$23,$22,$F0,$83,$32,$32,$2F
                DTA $02,$32,$21,$0F,$F0,$23,$22,$10,$FF,$08,$32,$22,$21,$F0,$83,$22,$22,$1F
                DTA $40,$22,$10,$6F,$F4,$02,$21,$06,$FF,$03,$22,$22,$10,$F0,$32,$22,$21,$0F
                DTA $54,$01,$07,$6F,$F5,$40,$10,$76,$FF,$08,$32,$22,$21,$F0,$83,$22,$22,$1F
                DTA $55,$40,$77,$6F,$F5,$54,$07,$76,$FF,$03,$21,$21,$10,$F0,$32,$12,$11,$0F
                DTA $54,$40,$76,$6F,$F5,$44,$07,$66,$FF,$02,$10,$10,$00,$F0,$21,$01,$00,$0F
                DTA $54,$40,$76,$1F,$F5,$44,$07,$61,$FF,$00,$00,$00,$00,$F0,$00,$00,$00,$0F
                DTA $44,$40,$66,$1F,$F4,$44,$06,$61,$FF,$58,$54,$08,$88,$F5,$85,$40,$88,$85
                DTA $44,$10,$66,$1F,$F4,$41,$06,$61,$FF,$45,$44,$08,$55,$F4,$54,$40,$85,$5F
                DTA $14,$10,$61,$1F,$F1,$41,$06,$11,$FF,$44,$41,$05,$44,$F4,$44,$10,$54,$4F
                DTA $01,$10,$61,$0F,$F0,$11,$06,$10,$FF,$44,$10,$08,$54,$F4,$41,$00,$85,$4F
                DTA $F0,$10,$10,$FF,$FF,$01,$01,$0F,$FF,$44,$41,$05,$44,$F4,$44,$10,$54,$4F
                DTA $FF,$00,$0F,$FF,$FF,$F0,$00,$FF,$FF,$41,$10,$04,$41,$F4,$11,$00,$44,$1F
                DTA $FF,$F0,$FF,$FF,$FF,$FF,$0F,$FF,$FF,$10,$00,$04,$10,$F1,$00,$00,$41,$0F

In main init code I just copy each of these rows on it's proper place in memory with $100 offset per row.

Graph paper rules !

[tschak909]

Very cool. I have my hands full with two contracts, but I will be keeping an eye on this ,and messing with the ideas as I get a few free cycles.

 

I'm trying to think of a sane color palette for something like Pengo. You'd need:

 

Black background

Blue for ice blocks

White for highlight color

Red for penguin body

two or three colors for stage color changes...

maybe an additional secondary highlight colour?

 

-Thom