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

[masteries]

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]

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 and never will be a programmer, but any help will be fine.

[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.

[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.

[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.

[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]

[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,

[dhedberg]

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!

[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

[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...

[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]

WOW, just WOW
Thank you dml!

[dma]

Excellent, looking amazing on that poc already.

[dml]

A short video to go with the earlier BG/tilemap animation update:

https://www.youtube.com/watch?v=Rtpv_gpBh7g

[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?

[dml]

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.

[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

[dml]

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.

[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?

[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.

[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?

[dml]

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).

[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

[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

[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