8-way scrolling system for prototyping games on STE

[dml]

I think the main thing would be how similar your block display and collision code is to mine. I try to keep my coding very modular and non hardware specific.
It will be very interesting to see the workarounds needed for the ST

Well there's a lot I could say on this topic (I won't go into the exact reasons why here) - but rather than explain it all, it might be better to play with the code on an ST and try to understand the way it operates.

BTW this system doesn't really draw blocks - it draws shards. This helps avoid spiking, which is important for 1-vbl games.

The simplest summary - and one that applies to most of my stuff - a bit of extra complexity and compute can buy you a lot less work.

It is divided into clear components with responsibilities and limited communication between them - so in that respect you could say it is 'modular' or has modular properties. It also implements many of the important bits without being platform specific (68k optimization aside) - not because the aim was to make it platform independent, but because the chosen methods perform better (for these use cases, at least) and are more adaptable. However it is very specifically targeted at STs. It doesn't pretend to be portable. It is made to rapidly put together high performance games for STs with no priority given to programming style, model or principles. All of those things are less important than how it performs (as a prototyping platform, and on the machine).

There are definitely a number of odd things about the source that seem inconsistent and for anyone used to cosy 3ghz PC development probably looks 'just wrong' - like the weird choice of using a C++ template to wrap the playfield/framebuffer engine, mixing object-orientated interfaces with C-like call sequences - or calling C functions from an assembly language algorithm. However, there are design choices behind all of that - not accidental. Much has to do with performance, configurability of code, compactness of setup code, accessibility of certain areas for quick prototyping and leaving important areas open to replace or modify.

I'll explain some of it in the wiki docs later.

Anyway, it'll be interesting to see if you can make use of it. An alpha release isn't far off. I'll post here about it soon.

[dml]

Slab sprites (up to 256 wide by display height) can now be clipped at viewport top and bottom without wasting framebuffer memory in the various scrolling modes. Left/right clip will use a shared margin/guardband area. Will add a sample soon demonstrating this.

Some speed improvements for slab drawing have also been made. There have been some changes to the slab file format to accommodate clipping so I'll upload v0.29 soon.

I'll be working on a faster way to erase larger slabs next.

I have built a version of the agtcut tool for MacOS/x64 but it's missing one of the 4 sprite modes since one relies on the RMAC assembler to generate binary code for the sprite file. Will get around to this later. I have been told that the Win32 agt tools do work on MacOS under homebrew/WINE though, as a way to get things going - they are just commandline programs after all.

I might be ready to post the first source release during the week or next weekend. I'll combine it with the existing tool repo.

[dml]

- new agtcut v0.29 on bitbucket (source + download)
supporting the new slabs format (for clipping) and background tile tagging via .csv file, which was used in the abreed example for reporting solid tiles
- new agtrip v0.3 on bitbucket (source + download)
with better support for different scroll directions, rates & importance masking for parallax areas etc.

Have now also created a proper usage.txt for agtrip.

[dml]

Last night I got compound sprite clearing to work on the 'slab' sprite method (giant sprites), in combination with the y-clipping.

Here's a very early preview of the demo/example for that use case (W.I.P - not finished!).

https://dl.dropboxusercontent.com/u/129 ... sscore.msa

Note that earlier examples of this were at 25hz because clearing records were initially generated per object scanline, as a temporary measure. This latest one is 50hz with some time to spare for music, game stuff & bullets.

There are still some issues with this, since it requires a special operation for clearing and it's not fully automatic yet - but I'll tidy up those parts and add the sample to the repo later in the week so it should also be part of the first release.

[mrbombermillzy]

Looking great there!

I quickly gave it a bit of a run (under Hatari emulation admittedly) on various systems.

It seems like you've managed to cram it into 1MB including the graphics.

Im wondering how close the ST/STE verions are going to be speedwise?

I cannot wait to see this let loose dml!

[dml]

Hi!

Looking great there!

I quickly gave it a bit of a run (under Hatari emulation admittedly) on various systems.

It seems like you've managed to cram it into 1MB including the graphics.

Yes I didn't check the memory commit yet but its somewhere between 512k and 1mb.

Im wondering how close the ST/STE verions are going to be speedwise?

I cannot wait to see this let loose dml!

Hopefully by the weekend ill be ready with early source release the slab clipping & clearing was bugging me for a while so that's more or less done now.

The STF support will obviously suffer with lack of a blitter - especially right now because I haven't coded the special STF sprite routines yet (just the standard/general purpose one so far). However a lot of the methods still translate well enough. It will definitely be more expensive ram-wise due to preshifting, more codegen and more framebuffers (for hscroll case). It therefore needs its own tuned examples/demos - they won't be 1:1 with the STE versions.

I'd say that most of what you see on STE at 50hz will be 25hz on STF - although some will still be doable at 50hz with care over sprite size & usage (as seen in much earlier samples in this thread). The slab method is still possible on STE since masking is not required between span edges but preshifting something that size is probably not too friendly on ram - so either size or speed will be impacted here.

In any case I will release STE support first and then go back and see what needs done to catch up on STF.

[mrbombermillzy]

Thanks for the info.

Bear in mind, theres alot of shall we say pre-STE systems out there WITH blitters!

Personally, I have a Mega ST1 with one (most Mega ST's had blitters) and Im sure there are a few STFM's and such with them in.

[dml]

Bear in mind, theres alot of shall we say pre-STE systems out there WITH blitters!
Personally, I have a Mega ST1 with one (most Mega ST's had blitters) and Im sure there are a few STFM's and such with them in.

Yep I have an old Mega-4 here too I'll aim to keep the blitter stuff separate from the STE support. Although in this early version they might be a bit tangled up still...

The main issue with separating blitter from STE is the fact you then have to treat it as optional at runtime - and then have to manage 2 kinds of data asset for blitter-supporting ST programs (one asset prepared for blitter, another for software). That will also mean extra config/setup logic that will be down to the programmer. So far that's not too hard (change the filename and the drawtype field) but there may be other cases where it creates some extra work for the programmer.

[mrbombermillzy]

I see what your'e saying there. Hopefully all the build options are not going to get too out of hand.

I take it your Mega 4 has a blitter?

Its great that you have a 'real' Mega because that would be the machine to test your code on. especially if its really tight timing wise. It seems the Mega range is a bit 'special' when it comes to cycle exact timings!

[Eero Tamminen]

Here's discussion about Worms for Falcon:
viewtopic.php?f=28&t=30454

I guess this engine could be also used for implementing something like that for STE too.

[dml]

I guess this engine could be also used for implementing something like that for STE too.

I suppose it could - if someone wants to give it a shot!


Still trying to get the code ready for upload. Support for horizontal and multiway oriented maps was fine but support for vertical was lagging behind - this has almost been caught up now.

Have reworked the samples to share some common data, to help keep the size of the repo down a bit. Other than that not much new to report.

[dml]

Still on track for making a code release within days. Just reviewing code comments in the header files etc. to make sure most things are described at a minimal level prior to wiki docs.

I'm also working on some Mappy (PC game map editor) integration demos which should help with game content editing. I probably won't get that finished in time for the first version but will follow soon afterwards. Map import is working but should be possible to use layers for defining solid tiles and maybe placing some kinds of entities - although not sure yet how far Mappy takes that side of things.

[dml]

As promised, a first cut of the AGT source code is now on BitBucket:

https://bitbucket.org/d_m_l/agtools

(I'll probably start a new AF thread aoon to announce properly and post future updates there).

I have added a single sample - the Gradius horizontal SHMUP game demo. It's probably a bit too advanced for a first example but the source is very well commented and it probably makes useful reading as it uses a lot of features at once. I'll add the other samples after I've had a chance to check all the comments. tidy up and ensure no missing files.

To build and work with the code you'll need Atari m68k-mint GCC from Vincent's website. This can be installed for Windows under Cygwin/32 or on MacOS (with the agt bin/ tools usable via WINE). This should work equally well for Linux, but hasn't yet been tested (!)

http://vincent.riviere.free.fr/soft/m68k-atari-mint/


To build the game data run the makedata shellscript in the demo project dir. If your environment is working as planned, it should generate sprites etc. and will take some minutes to complete. The agtcut tool is configured with -v (verbose) so you'll see a lot of spam from the sprites.

> ./makedata.sh


Then compile the code. This should be quick...

> make clean; make

You should then be able to run the game from the game project dir, or point an emulator at it via gemdos share (game will boot from auto/)


Notes for MacOS users:

The tools are currently all Win32 - but can be used from a MacOS/Darwin shell by installing WINE (via Homebrew for Mac). (thanks Matt for confirming this!). I'm hoping to provide native Mac binaries for the main tools but this may take time. WINE does the job for now.


Since this is a first cut of the engine, it's likely to see further changes. In other words - if you decide to start doing anything with it, expect to fix some stuff later when things change. I don't expect major reworking but... be aware of this. (Worst case you can get in touch with me and I'll help sort out any changes).

Some things are still missing and due in a later version:

- documentation (!) although the tools have usage guides, the game sample is well commented and the bitbucket wiki will grow
- more & simpler examples - some are almost ready to add but need some cleanup
- STF support (was disabled to focus on STE and now lagging)
- more advanced memory/asset management for 'production' games
- decent font support (currently must be done with sprite strings)
- builtin sound effects handling (although you can still do your own meantime)
- support for parallax effects
- some more advanced features


Last... if you're interested in this project, keep an eye on the bitbucket page for updates to the docs. I'll be adding more detail there soon.

Happy game coding...

[EDIT]

Nearly forgot to add - there are also some credits due for bits and pieces and tool work (esp. RMAC). which will be added soon too...

[dml]

Additional:

Word of caution when building sprites for Gradius with ./makedata.sh

When producing the optimized EMXSPR format as used by the game demo, the 'agtcut' tool tries to call the RMAC assembler for each sprite frame. If rmac.exe is not found on the usual executable search paths it will stop with an error. For all other tools, the makefile refers to $(AGTROOT)/bin/. so there shouldn't be an issue.

Chances are rmac.exe is not on your search path after fetching the repository - you'll need to add it to your environment one way or another - so add the AGT bin/ dir to your path, or copy/link rmac.exe to an existing path (or some equivalent action that suits your system).

The other 3 sprite modes don't require RMAC since they don't involve code generation.

[metalages]

I know this idea will be boring...
But it would be cool to provide a linux (because it's free) VirtualBox (because it's free) virtual machine with all these stuffs setup correctly

[dml]

That's a fair point and I'm aware of the need for Linux support. OTOH, it's something which could *in theory* be done by someone else, while I continue to work on things that nobody else can for the time being (hint, hint!)

Aside: Since I'm unwell today I didn't do much but I was able to add some wiki basic docs on the Entity system used in the demos. I'll add more later.

[TheNameOfTheGame]

Hope you're feeling better soon! Thanks for the source release. I'm going to set up the environment and attempt to compile

[dml]

Hope you're feeling better soon! Thanks for the source release. I'm going to set up the environment and attempt to compile

If there are problems ping me and I'll try to help. It's a first release so things might be a bit bumpy at first.

[TheNameOfTheGame]

After some bumps (my fault), I can confirm it compiles and runs in Steem just fine. Nice job!!

P.S. makedata.sh took about 10 minutes on my (oldish) machine to finish.

[Anima]

Thanks Doug for releasing the sources and I hope you're getting well soon.

[mrbombermillzy]

Doug, for the initial release, the AGT system looks pretty polished! Thank you so much for sharing with us all.

Just getting my teeth into the docs, Im very pleased that I can understand what is being done here despite having a minimal understanding of C/C++. (I definitely fared better than the last Atari book I tried to read,'DSP programming using the Motorola DSP family'. That was a real bundle of laughs!).
This seems to be very cleanly designed and modular too. Just what I need to get to grips with it really.

I havent got very far, but Im loving the fact that you can repurpose the entity dictionary fields. I think that will come in very handy.

I had set up and was starting to use Pure C through Hatari so that I can learn C from 99% of the sample code for the Atari platform and build on both my weedy netbook dev machine and the real hardware without too much fuss (Im basically mirroring the netbook and Real Atari HDDs). I see I will have to change to GCC then! D'oh!

Im still learning Atari/C dev, so please forgive any ignorance, but with GCC adding extra lib overheads to the size of the code, what would be the minimum memory requirements/executable code size on real H/W just for the AGT system? Is it going to be the same sort of ballpark figure as the last demo?

[dml]

Thanks Doug for releasing the sources and I hope you're getting well soon.

Many thanks! Got a bit of a cough and not feeling too great still - but should be better soon

[dml]

Doug, for the initial release, the AGT system looks pretty polished! Thank you so much for sharing with us all.

Just getting my teeth into the docs, Im very pleased that I can understand what is being done here despite having a minimal understanding of C/C++. (I definitely fared better than the last Atari book I tried to read,'DSP programming using the Motorola DSP family'. That was a real bundle of laughs!).
This seems to be very cleanly designed and modular too. Just what I need to get to grips with it really.

Yep DSP programming books won't provide much encouragement (Especially that red book I'm thinking about).

I have tried to avoid using confusing constructs in the C/C++, aiming make it easy to pick up and adapt. There are some slightly more obscure language tricks in there but mostly hidden behind something or other (mainly inside the playfield system). The stuff you need to edit/work on for a game is deliberately kept very plain, just a level or two above the assembly.

I think of the C-based AI code as a sort of 'scripting language' for the 68k systems underneath. Many of the things happening in those functions are close equivalents to methods you'd use in 68k. I'm going to list the most common useful patterns on the wiki.

I havent got very far, but Im loving the fact that you can repurpose the entity dictionary fields. I think that will come in very handy.

While there are only a few dictionary (default) fields you can safely repurpose - there are several more dynamic ones you can steal for variables. I'll document those soon. (I'll probably add a few more spares in future versions too).

I had set up and was starting to use Pure C through Hatari so that I can learn C from 99% of the sample code for the Atari platform and build on both my weedy netbook dev machine and the real hardware without too much fuss (Im basically mirroring the netbook and Real Atari HDDs). I see I will have to change to GCC then! D'oh!

That is a bit of hassle, but GCC is more powerful generally. It has some issues but code generation is quite competent if you are careful to avoid lots of plain function calls.

Im still learning Atari/C dev, so please forgive any ignorance, but with GCC adding extra lib overheads to the size of the code, what would be the minimum memory requirements/executable code size on real H/W just for the AGT system? Is it going to be the same sort of ballpark figure as the last demo?

Good question - while it does (should!) work with the default MiNTlib and the STD C++ lib - which are gigantic and waste about 150-200k of ram - it's designed not to need them. The demos will all build without them. There is a minimal C lib layer in the project which requires only a few kb and is enough to do what is needed.

If you look in the demo makefile you'll see LINK_MINIMAL=yes which should give you small binaries. If you set that to =no (and I haven't tested it in a month or so!) it should link MiNTlib etc, and result in a huge executable.

I kept MiNTlib support mainly because it does have some extras which I have used in the past to help with debugging etc. It is required to support floating point functions for example, to help build & export music tables and so on. But it's definitely not essential. You work easily without it.

What you will see however (IIRC), even with 'LINK_MINIMAL=yes' is that uninitialised storage (the BSS section in a 68k program) doesn't get turned into true BSS in a GCC project. It tends to end up in a data section. This makes the executable look bigger - its just a lot of zeroes. This is storage that would still be allocated even if it were true BSS so nothing is really lost. It also disappears when the program is packed.

There is some waste in AGT which I haven't optimized away yet - particularly some sound tables are too large, and over-estimates for sprite clearing stacks and so on (which will become configurable). Apart from that its fairly lean.

Thanks for the feedback - its very helpful!

[mrbombermillzy]

If you look in the demo makefile you'll see LINK_MINIMAL=yes which should give you small binaries.

You really have thought of everything, havent you?

On another note..

With the slab draw entity type, Im not clear on how far from being square the image can be. I get that any pixels enclosed within the body of the image that are set as masked wont be, but what about e.g. an 'X' (or other irregular) shaped image where the x axis of a pixel may be between the body of the image but the y axis may not be?

Again, thanks for the information.

[dml]

On another note..

With the slab draw entity type, Im not clear on how far from being square the image can be. I get that any pixels enclosed within the body of the image that are set as masked wont be, but what about e.g. an 'X' (or other irregular) shaped image where the x axis of a pixel may be between the body of the image but the y axis may not be?

Again, thanks for the information.

Yes the SLAB type will have trouble with the X shape because there are gaps between the left/right contour. So you'll end up with something like this:

Code: Select all

111000000111
 1110000111
  11100111
   111111
  11100111
 1110000111
111000000111


..where the 1's represent your intended graphic and the 0's represent 'unexpected solid bits' which will be filled in the key or background colour.

So the SLAB shape can't handle vertical indentations but can deal with horizontal ones.

Having said that - I had planned to upgrade the tool to decompose slabs into pieces which don't break this constraint - and the pieces can be drawn in sequence to recover the original shape. This would mean 2 pieces for an 'X' shape, but could be many more if care isn't taken over design.

Providing the constraints are observed though, slabs can be far from square. e.g. you can encode diagonal shapes with reasonable efficiently.

[EDIT]

Oh - and you can still 'decorate' slabs with normal sprites, if they are kept small. This is best kept for animated/shootable parts of a bigger thing but it's another way to deal with limitations of the contour as a last resort.