[A]tari [G]ame [T]ools - 2D prototyping engine for STE

GFA, ASM, STOS, ...

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

Post Reply
masteries
Retro freak
Retro freak
Posts: 16
Joined: Thu Jul 16, 2015 4:05 pm

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by masteries »

shoggoth wrote: Sun Oct 25, 2020 7:33 pm I hear banjos playing.
If you are speaking about the Run & Gun demo; you are hearing only PCM (.wav) based sounds; music is based on various .wav pieces playing on a loop fashion, following a music sheet.

Yamaha2149 is not used at all; there are only 8 bits digital audio, monoaural sound, 3 voices mixed at 12,5 KHz.
Digital sound is not instrument restricted, you can hear anything you want, due to there are no synth instruments at all.
AnachronyX
Atariator
Atariator
Posts: 21
Joined: Sun Mar 08, 2009 12:33 pm

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by AnachronyX »

O.K., I'm down. I tried to install and compile your sources on Linux. I remember, that when I tried it about two years ago, it worked, but today I'm not successful. I tried it on Manjaro Linux (Arch based distribution) and get this error:

Code: Select all

make
m68k-atari-mint-g++ -c -m68000 -Ofast -fomit-frame-pointer -fstrict-aliasing -fcaller-saves -DAGT_CONFIG_WORLD_XMAJOR  -D__ATARI__ -D__M68000__ -DAGT_CONFIG_STACK=16384  -DAGT_TESTING_BUILD -DUSE_TINY_CRT -I../.. -I3rdparty/ -x c++ -std=c++0x -fno-exceptions -fno-rtti -fno-threadsafe-statics -Wall -Wno-reorder -Wno-narrowing -Wno-unused-variable -Wno-multichar -o ../../agtsys/system.o ../../agtsys/system.cpp
In file included from ../../agtsys/system.cpp:13:0:
../../agtsys/common_cpp.h:14:18: fatal error: string: No such file or directory
compilation terminated.
make: *** [../../Makerules:427: ../../agtsys/system.o] Chyba 1
"Chyba 1" = error 1.

It looks like it can't find #include <string> #include <vector>. O.K. I discovered, that "m68k-atari-mint-gcc 4.6.4-12" and "m68k-atari-mint-binutils 2.30-1" probably aren't a full version of Vincent Rivière's m68k-atari-mint cross-tools.

So I installed Ubuntu 20.10 in a virtual machine. I added PPA source and install m68k-atari-mint cross-tools, I set AGTBIN path, changed directory to tutorial0, wrote make and... got this:

Code: Select all

make
../../bin/rmac -fa +oall -i"`command -v cygpath >/dev/null && cygpath -C ANSI -w ../.. || wslpath -aw ../..`" -DAGT_CONFIG_WORLD_XMAJOR  -D__ATARI__ -D__M68000__ -DAGT_CONFIG_STACK=16384  -DAGT_TESTING_BUILD -DUSE_TINY_CRT -o ../../rmac/sys.o ../../rmac/sys.s
/bin/sh: 1: wslpath: not found
../../rmac/sys.s 9: Error: cannot open: "rmac/config.inc"
../../rmac/sys.s 69: Error: cannot open: "rmac/prf.s"
../../rmac/sys.s 284: Error: undefined expression
../../rmac/sys.s 285: Error: undefined expression
../../rmac/sys.s 392: Error: undefined expression
../../rmac/sys.s 400: Error: undefined expression
make: *** [../../Makerules:441: ../../rmac/sys.o] Chyba 6
I know, I know, probably I'm so stupid :shrug: and never will be a programmer, but any help will be fine.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

This is probably not your fault - more likely recent changes to support WSL and Cygwin together have broken builds on Linux. It looks like it is using WSL rules here when it should not be.

I don't know when I'll get a chance to look at this but I'll make a note that it needs attention.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

[UPDATE]

I pushed one more small example (bganim) which demonstrates animation on a single layer background.

The new sample differs from the previous BG animation example (layeranim) in the way the animation frames are cut, making things simpler for the single-layer playfield case (i.e. the most common case).

'layeranim' defined a 2-layer playfield where the top layer was transparent and initially blank/empty. The single 'map' which was cut for the 2nd layer was not loaded directly into the playfield, but used as an asset store for the animation frames. Animation was applied by copying rectangles from that map to the empty top playfield layer. In other words there was only one map and one tileset, per layer. AGTCUT could only process one map per tileset at a time, so things worked out ok.

This becomes a problem though if you want to have a map AND a separate minimap full of animations, sharing the same tileset - AGTCUT would not support it. This is exactly what happens if you try to animate tiles on a single-layer platfield, because the layer is not empty to begin with - it has a real map, and animations are coming from a *separate* map. Possibly even more than one map, if there are lots of animations to manage.


This has been addressed for the new sample - its now possible to define multiple pages of animation frames on separate images and cut them simultaneously with the main map, all sharing one tileset. This allows animation frames to be stored separately from the main map, in separate assets. The frames can be copied to the playfield using the same map block copy primitives used in 'layeranim'.

Steem__00152.png
Steem__00153.png
Steem__00154.png

There are 2 independently animating regions in the background (different rates, different loop points). These are driven by invisible entities.

bganim_map_index.png

The sprites are only there to show objects moving on top of the animations.


This change does also allow multiple game levels to share one tileset of course. But it was more of a blocker for tile animation, since loading new tiles per level is pretty much expected most of the time anyway.

...

I have not had time to look at the Linux build issues - I don't really have an environment set up for it just now, except maybe the RPI - but it will be a hassle to get everything set up again. I'll look at that when I have more time to spend on it.
You do not have the required permissions to view the files attached to this post.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

[UPDATE]

Just a tiny update this time.

The built-in entity_t structure - which defines all the variables owned by a game object (position, velocity, drawing method etc. etc.) - was becoming restrictive in cases where more complicated AI/tick behaviour is needed.

While there have always been a few reserve 'user' variables available, is still possible to just run out of free ones, forcing the programmer to find confusing workarounds, which can in turn cause bugs. Reusing general purpose variables also makes the game code harder to read if you've been away from it for a month etc.

I had been aware of this issue while working on the demos/samples myself but it has gone up in priority since Masteries' Metal Slug demo started to introduce more and more game objects and it was getting in the way of progress.


Anyway to resolve this I made some small changes which allow the entity_t to be redefined (really, extending the built-in definition) locally in the game project, so you can add all the custom fields you want for your game. The engine itself doesn't need to see the extended definition, it can be entirely project-local.

This feature is not enabled by default but can be configured in the makefile by adding the AGT_ENTITY_USER_EXTENSION definition. I may adopt that as the default at some point in the future since changes required on the game side are really minimal.

I will probably do more with this in future to make it a bit more powerful, but it is usable now as-is.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

[UPDATE]

It is now possible to generate EMS/EMX sprites which consume a fraction of the memory, at the cost of 'snapping' to a grid on the x axis. This basically omits some of the EMS/EMX preshifts for offsets which aren't needed ingame.

e.g. passing '--preshift-step 16' (or '-pss 16') will generate a preshift for every 16th x-position, requiring 1/16th the storage cost.

'--preshift-step 2' will half the cost of a sprite which moves at a velocity of 2 pixels, always starting on even pixel.

No changes are required in-game to support this, it is specified only while cutting the sprite asset. This makes it simple to use and an easy way to go back and optimize sprite memory usage in later stages of your game.

Masteries will be using this (and some other tricks) to squeeze more graphics into his Metal Slug project.

There are a few other things in the works but I'll wait until I can see them working before reporting. A lot of this is subject to how much time I can find to play with Atari things...
masteries
Retro freak
Retro freak
Posts: 16
Joined: Thu Jul 16, 2015 4:05 pm

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by masteries »

dml wrote: Sat Oct 31, 2020 12:02 pm [UPDATE]

It is now possible to generate EMS/EMX sprites which consume a fraction of the memory, at the cost of 'snapping' to a grid on the x axis. This basically omits some of the EMS/EMX preshifts for offsets which aren't needed ingame.

e.g. passing '--preshift-step 16' (or '-pss 16') will generate a preshift for every 16th x-position, requiring 1/16th the storage cost.

'--preshift-step 2' will half the cost of a sprite which moves at a velocity of 2 pixels, always starting on even pixel.

No changes are required in-game to support this, it is specified only while cutting the sprite asset. This makes it simple to use and an easy way to go back and optimize sprite memory usage in later stages of your game.

Masteries will be using this (and some other tricks) to squeeze more graphics into his Metal Slug project.

There are a few other things in the works but I'll wait until I can see them working before reporting. A lot of this is subject to how much time I can find to play with Atari things...
This new option is pretty awesome, if you are careful enough, you can save a huge amount of RAM without any noticeable side effect!

Thanks to this, the progress and number of different sprites on Mission 1 and Mission 5 Metal Slug levels development is reaching arcade resemblance,

More surprises are coming... thanks to dml doing the best,
User avatar
dhedberg
Atari God
Atari God
Posts: 1205
Joined: Mon Aug 30, 2010 8:36 am
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dhedberg »

masteries wrote: Sun Nov 01, 2020 1:01 am Thanks to this, the progress and number of different sprites on Mission 1 and Mission 5 Metal Slug levels development is reaching arcade resemblance.
Oh boy! I think this is one of the most exciting projects lately! Keep it up! Keep posting progress reports, previews, videos, etc!
Daniel, New Beat - http://newbeat.atari.org.
Like demos? Have a look at our new Falcon030 demo It's that time of the year again, or click here to feel the JOY.
User avatar
LaceySnr
Captain Atari
Captain Atari
Posts: 188
Joined: Wed Jun 26, 2013 5:00 am
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by LaceySnr »

Oooh, the entity definition updates sound handy.

"Reusing general purpose variables also makes the game code harder to read if you've been away from it for a month etc." I know you know I've been there :D
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

Thanks guys. I've been kinda busy but trying to squeeze a few Atari things here and there.

[UPDATE]

I think there have been a few comments on different forums concerning the STE and lack of fast/usable parallax support for games.

I didn't want to let that one go un-addressed in AGT, so here we are!

320x272, 16 colours, 4 parallax regions and sprites at 50Hz with room to spare.

https://www.youtube.com/watch?v=L-H-lZFWg6k

It is not actually limited to 4 parallax regions, but I couldn't find a decent arcade background to use for this example. So I ran with 4.

There are other kinds of parallax possible with AGT but they are a bit more effort to set up. I haven't had the time to example them yet.

More on the way, soon...
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

[UPDATE]

If it's not obvious from the previous video, I have actually added support for multiple viewports:

https://www.youtube.com/watch?v=XLKd-f9QJcY

This is a modified version of the older 'abreed' demo, with two views on the same game world. The sprites seen in both views are actually the same entities.

The parallax effect in the previous video in fact uses 4 different viewports stacked on top of each other to perform the decoupled scrolling.


There is a bit more to this than meets the eye - each viewport is defined by an 'arena', which is made from a set of playfields (framebuffers), each of which is updated independently as a distinct game view. You can actually load different maps (of different sizes!) and tilesets into each viewport if you like.

The same sprites/entities however are rendered into all viewports. I may upgrade it in future to maintain more than one game state, so a different game can run in each viewport. Because... well because we can.

The parallax demo actually uses a slightly stretched (7:6) version of the main map & tiles in the 4th viewport, to make the parallax work better.

The screen splits are implemented with a kind of TimerB copperlist/chain. Each arena can specify which screen split it is bound to on the hardware side. This part is not openly programmable yet, but I will probably allow the split configuration to be specified from the game code soon, and updated at runtime.
Gnu
Atariator
Atariator
Posts: 23
Joined: Fri Feb 20, 2004 2:37 pm

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by Gnu »

8O WOW, just WOW 8O
Thank you dml!
Don't believe everything that is true.
User avatar
dma
Atari God
Atari God
Posts: 1142
Joined: Wed Nov 20, 2002 11:22 pm
Location: France
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dma »

Excellent, looking amazing on that poc already.
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by calimero »

This is amazing!

Hope that someone in future will put these in good use :)
Beside making great arcade conversions, this new ability open new possibility for quite original games!
Some multiplayer, maybe Utopos like, games for 4 players using STe additional joystick ports? :)

Btw Doug,
Is there a support for horizontal split? To have 2 x 2 gaming area (first game come to my mind is Skid Marks for Amiga)? Will this be even possible with STe hardware?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

calimero wrote: Sat Nov 07, 2020 8:11 am Is there a support for horizontal split? To have 2 x 2 gaming area (first game come to my mind is Skid Marks for Amiga)? Will this be even possible with STe hardware?
That's something you can do on consoles with programmable HW displaylists etc. STE can only just manage to reconfigure the display registers at the start of a scanline, so splitting the screen vertically (with horizontal partitions) is the best we can do for 'free'. Even this approach isn't exactly free but it is a lot cheaper than copying graphics around.

You can do more tricks which are not so free, but the point here is to keep the CPU under very light load so it can run a decently interesting game.
User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2378
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by calimero »

My bad: SkidMarks on Amiga have only split screen, not 4way split...

Anyhow, does this mean that Thunder Cross demo can have paralax scroll now? :) https://youtube.com/watch?v=DfiaooqDGFg
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

calimero wrote: Sun Nov 08, 2020 6:18 pm Anyhow, does this mean that Thunder Cross demo can have paralax scroll now? :) https://youtube.com/watch?v=DfiaooqDGFg
Yes that one could have parallax quite soon :) not quite yet but soon...

That demo isn't a particularly good one - I just took the game code from the other Nemesis demo and set up a different palette and background. The objects all appear in the wrong place for the much taller background.

But it takes time to make all these samples and I need to keep moving on. Maybe we can replace them with better contributed ones in future.
User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1468
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by TheNameOfTheGame »

Were the problems with compiling under Linux fixed? I'd like to try my hand at compiling the examples.


*Edit* Went ahead and pulled the repo down and installed the dependencies. Trying "make" in the bganim example gives errors:

Code: Select all

../../rmac/sys.s 9: Error: cannot open: "rmac/config.inc"
../../rmac/sys.s 69: Error: cannot open: "rmac/prf.s"
../../rmac/sys.s 284: Error: undefined expression
../../rmac/sys.s 285: Error: undefined expression
../../rmac/sys.s 392: Error: undefined expression
../../rmac/sys.s 400: Error: undefined expression
../../Makerules:441: recipe for target '../../rmac/sys.o' failed
So I assume this is the Linux issue and it is still present. I see you mentioned you don't have a Linux target to test with. Maybe you could set up a virtual machine with Linux to test on?


*Edit 2* Got it to compile by replacing

Code: Select all

include		"rmac
with

Code: Select all

include		"../../rmac
for each error. A lot of manual editing of files.


*Edit 3* Running the compiled program in Steem throws some errors.

error.png

Looking in the example folders, these are the files after the compile.

files.png


Why am I missing the shared.cct and sprite.ems files and what is the assert error from?
You do not have the required permissions to view the files attached to this post.
Last edited by TheNameOfTheGame on Mon Nov 09, 2020 2:44 am, edited 2 times in total.
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

I started working on it today, via MacOS. I was able to reproduce most of the errors, which are caused by some recent WSL build changes among other things.


However the most difficult & annoying ongoing problem - and the reason for things breaking so often re: paths - is the fact AGTCUT launches RMAC to assemble generated code for EMX sprite frames. This does not play well on any of the Posix systems even using WINE to wrap them, partly because there are temporary paths passed between the tools, which can be in the wrong FS space.

To make matters worse, Apple dropped 32bit support in Catalina and WINE doesn't work properly anymore. So the Mac version can no longer call any of the Windows .exe tools.

So I now have to consider native versions of all the tools. Which sounds good, except I don't have build automation/testing for 4 targets - it needs done manually. Which takes time away from working on the engine.

I have build AGTCUT natively under WSL with GCC last week for testing and will soon try the same for Mac with Clang. If it builds on Mac it will build on Linux too.

PCS was already Posix-clean so it should build on any of them without much work.

RMAC is available on Windows & Mac, but not Linux currently. It may have to remain wrapped with WINE for now.



Anyway I'll try to fix these path issues first and come back to the tools problem afterwards.
User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1468
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by TheNameOfTheGame »

Thanks for checking on the issue. I made an edit to my post regarding errors when running the compiled program. Can you tell from my screenshots why this is happening?
User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3627
Joined: Sat Jun 30, 2012 9:33 am

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by dml »

TheNameOfTheGame wrote: Mon Nov 09, 2020 2:43 am Thanks for checking on the issue. I made an edit to my post regarding errors when running the compiled program. Can you tell from my screenshots why this is happening?
You will need to run the ./makedata.sh script to build the assets (the sprites and the map)

However I believe it will fail for the same reasons the RMAC wrapper failed on Linux. So you may still be stuck.

(That assert occurs because the playfield tries to go live with no assets attached to it, having failed to load any. It can also occur if the files are there but the system runs out of file handles, which seems to happen under Steem if you just keep using warm reset, i found).
User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1468
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by TheNameOfTheGame »

Actually, running makedata.sh worked first time. Maybe because I made the changes earlier?

Now the example is running in steem. Thanks for the help.

example.png
You do not have the required permissions to view the files attached to this post.
User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1468
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by TheNameOfTheGame »

Tried another example "giantsprites". It compiled first time. Same with makedata.sh. So the problems with Linux seems to only be the paths to the rmac directory files.

example2.png
You do not have the required permissions to view the files attached to this post.
User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1468
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: [A]tari [G]ame [T]ools - 2D prototyping engine for STE

Post by TheNameOfTheGame »

Trying the remaining examples. "layeranim" compiles and works in steem.

"map8x8", "map8x8x2layer" and "map16x16x2layer" all fail from "make" with the error:

Code: Select all

../../bin/upx -9 map8x8.tos
wine: Bad EXE format for Z:\home\user\Projects\agtools\bin\upx.exe.
../../Makerules:300: recipe for target 'map8x8.tos' failed
make: *** [map8x8.tos] Error 193
*Edit* Changing the line from the Makefile

Code: Select all

# =============================================================================
#       Pack final executable (only used in 'release' mode)
# =============================================================================
USE_UPX_PACKER=yes
to

Code: Select all

USE_UPX_PACKER=no
fixes the issues with the "map" examples. What target Windows version is your upx.exe?

*Edit* Looks like you're using the 64-bit version of upx.exe. Downloading the 32-bit version and replacing the file from your repo fixed the "make" error.

There is some corruption on the "map" examples though. See the image below. Can you reproduce this?

example3.png
You do not have the required permissions to view the files attached to this post.
Post Reply

Return to “Coding”