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

[dml]

[UPDATE]

Have pushed a new sample 'examples/layerani' which demonstrates how to set up a 2-layer playfield and apply animaton to the top layer.

This example shows trees growing slowly and independently at random locations around the map. They are not location-specific - in other words, the tree graphics are independent of the other background graphics and are masked on top.

In fact both playfield layers can be animated independently if needed.

Map asset containing the tree shapes. As with any playfield map, this consists of a map file and a tile library.

layerani2.png

Sample showing the background with the trees growing on top:

layerani.png

Dual-layer playfields are enbled with the PFA_DualLayer attribute in the playfield config.
Tile animation is enabled with PFA_TileAnimation.


Animating the base layer is useful for things like opening doors, animating water, damaging scenery etc. Many of these cases would be map location specific.

Animating the top (transparent overlay) layer is useful for things like animated shrubbery, switches and other reusable things which might be placed anywhere at multiple locations on the base layer.

Since this type of animation uses tilemaps and is part of the background, the cost is very low so long as the animation is infrequently updated. While you could achieve the same with sprites, you'd be paying the cost of those sprites every refresh.

Some primitives are provided to assist with copying rectangles, rows and colums from a loaded map asset to the active playfield - either base or top layer.

Maps (general purpose or active playfields) can also be created & filled at runtime, without loading them. In this sample, the 2nd playfield layer is created empty. The trees are placed at runtime.


Animation is achieved by creating invisible entities (again! ) which apply map edits in their tick functions. This makes them easy to place in a map editor, or from a spawn schedule.

[Playmobil]

Woooow ! Amazing !

[LaceySnr]

[UPDATE]

Have pushed a new sample 'examples/layerani' which demonstrates how to set up a 2-layer playfield and apply animaton to the top layer.

Just did a pull so I can run this example and it looks great. Gotta get this running on a CRT sometime Will definitely to use some animated tiles so thank you (though right now I'm busy writing out binary trees in big endian ).

[dml]

Thanks for trying it

Good luck with the endian tree adventure.

[EvilFranky]

Doug, us mere mortals need a video or 2

[TheNameOfTheGame]

This project is amazing.

[dml]

I'm still working on a few things - if I can get those done soon I'll try to catch up with a video.

[dml]

[UPDATE]

A minor but useful improvement provides a frame-slipping implementation of vblank sync.

This lets you prepare 3 buffers (or 4, in dual-field mode) in the playfield config and lock to a minimum period of 1 vblank (or 2 if required, for slower games).

Now if your game runs mostly in 1 vbl while occasionally dropping frames in busy areas, this will hide most of the drop, providing something like 47fps - instead of mostly 50fps with obvious drops to 25.

This can be done by calling shifter_ste::wait_vbl_minbound(), while providing a minimum number of vblanks to wait. A local variable is also passed to track the time since the last visit to that site, in case it gets used in more than one place.

[dml]

There are a few more things on the way but it will take some time to get them ready.

[unseenmenace]

Apologies if this has already been covered, I did try searching the topic, but does anyone know roughly what the CPU usage is for multi-directional scrolling (16x16 tiles) with this?

[dml]

Hi, sorry for the silence but I had a lot of things going on last couple of weeks.

Multi-directional (like 8-way or omni-way, whatever) scrolling cost will depend a bit on the speed at which the camera is moving. If you're scrolling at 1pix per frame then it will just be a handful of scanlines (I don't remember how many, but cost is small). If scrolling diagonally then it will be about 2x-3x that.

Tiles are drawn incrementally in scanline slices to regulate spikes so it doesn't cost very much at low scroll speeds. At 1 pix per frame and 2 buffers, each slice is 2 pixels high (2 pixels moved & drawn, every 2nd frame).

If the camera is moving 8 pix per frame (i.e. very fast) then it will be more because larger tile slices need drawn - a whole tile in fact for a double buffered playfield. This is currently the scroll speed limit in AGT (otherwise you can get holes in your map, at least until I update that bit).

Scroll speed can be arbitrary, if you maintain your camera pos & velocity as 16:16 fixedpoint you can scroll at e.g. 0.7 pix per frame on one axis and 1.9 on the other.


The primary cost in AGT isn't so much the scrolling but sprites and their background refresh/unpainting pass. And to keep on top of AI tick costs.


There is a built in sampling profiler and metrics gathering and a debug console to help with the AI cost measurement. It can list how many of each kind of entity is active every second or so.

[lastic]

First off, what an amazing project !

I've been trying to run the isometric scroll demo on both Hatari and a 4MB STE but seem to be stuck.
Using the isoscrol.prg in the AUTO folder, p2e seems to be unable to find the assets , using the isoscrol.tos , I get stuck on the loading tiles ... part

[dml]

Hi, thanks for the interest.

I've been trying to run the isometric scroll demo on both Hatari and a 4MB STE but seem to be stuck.
Using the isoscrol.prg in the AUTO folder, p2e seems to be unable to find the assets , using the isoscrol.tos , I get stuck on the loading tiles ... part

Is it just isoscroll that seems broken? Or are the other demos also broken? I won't get time to look at it today but I'll try on Monday. Maybe I forgot to commit something to the repo for that sample. Asset compression was one of the last things I added, so it is possible.

Make sure you run ./makedata.sh to generate the assets. It could be that data files in the repo are stale, if there are any. The makedata script will build them from scratch, except maybe the palettes as I usually disable that in the scripts if the generate time is high, committing the output file to the repo for convenience. Also make sure all assets are in the root directory of the disk, not in the auto folder or anywhere else.

[lastic]

I seem to have the issue with every demo, I did run makedata.sh first before running make.
When running the isoscrol.tos , all the assets are in the same directory of a folder ISOSCROLL on my UltraSatan SD card that I use for my STE.
Should I put them in my root folder on the SD card ?

Thanks for looking into this.

[Eero Tamminen]

To debug file path/name issues with Hatari, use its "--trace os_base" command line option. Adding ",gemdos" to trace options will tell a bit more, but typically os_base trace (execs & file opens) already tells enough.

[lastic]

Bosscore, h-shmup and hv-shmup work on both Hatari and the 1040STe after I gave it a new try.

So it does seem to be isolated to ISOSCROLL .

[Xerus]

Hi dml,
I don't know if you plan to do all of this but it would be nice to have the following options in your super engine:

- Palette Split for 2 (or much +) distinct palettes on screen;
- Rasters (horizontal bars in background);
- Splitscreen display for parrallax or a separate HUD. Each display part can be scrolled with (hardware) scrolling parameters;
- Sprite by interruption as Blood Money, to have one sprite in 50 i/s and other to 25;
- Add Lance Protracker replay (available on DHS Site);

After release Crownland, my brother is very tempted to use AGT for his next game!

Anyway, bravo for all your achievements on our Atari!

[dml]

Hi,

So it does seem to be isolated to ISOSCROLL .

Thanks. I didn't quite get around to this on Monday, but looking at it now.

[dml]

Hi Xerus,

After release Crownland, my brother is very tempted to use AGT for his next game!

Anyway, bravo for all your achievements on our Atari!

Thanks for the feedback/suggestions. Hopefully your bother finds time to try it out.

Some of the items on your list were in progress, some could be added, others might be difficult to make work as-is, i will need to think about configurability and how features tie to specific display modes.

At this moment I don't have time to work on new features but will pick things up again soon.

[dml]

Hi again,

So it does seem to be isolated to ISOSCROLL .

Having purged & rebuilt everything from the repo, I found the following:

- I had pushed a debug build of agtcut, which was *incredibly* slow. It might not have completed building the data, or got interrupted? I have pushed a release build now. Might be a good idea to re-run ./makedata and ensure it completes the job.
- Isoscroll had been pushed with the vbl wait disabled. I had been changing the interface for this recently and must have missed it. But this would only cause the demo to scroll too fast. It is now fixed.

I can't reproduce an issue with actual loading of data files. What do you actually see when the issue happens? Does it show an error on the TOS screen or does it display any graphics before it stops?

[lastic]

Hi again,

So it does seem to be isolated to ISOSCROLL .

Having purged & rebuilt everything from the repo, I found the following:

- I had pushed a debug build of agtcut, which was *incredibly* slow. It might not have completed building the data, or got interrupted? I have pushed a release build now. Might be a good idea to re-run ./makedata and ensure it completes the job.
- Isoscroll had been pushed with the vbl wait disabled. I had been changing the interface for this recently and must have missed it. But this would only cause the demo to scroll too fast. It is now fixed.

I can't reproduce an issue with actual loading of data files. What do you actually see when the issue happens? Does it show an error on the TOS screen or does it display any graphics before it stops?

So I deleted the agtools folder and did a new git clone.

I think the issue lies here

Code: Select all

UCL data compression library (v1.03, Jul 20 2004).
Copyright (C) 1996-2004 Markus Franz Xaver Johannes Oberhumer
http://www.oberhumer.com/opensource/ucl/

pack2e.exe: using block-size of 4194304 bytes
pack2e.exe: algorithm NRV2E-99/10, compressed 228818 into 53228 bytes
../../bin/packwrap: line 3: /cygdrive/c/Users/<WINDOWS_USER>/Downloads/agtools/bin/packwrap.exe: Accessing a corrupted shared library
make: *** [Makefile:200: villager.pmx] Error 126

When I run make again , it continues

Code: Select all

UCL data compression library (v1.03, Jul 20 2004).
Copyright (C) 1996-2004 Markus Franz Xaver Johannes Oberhumer
http://www.oberhumer.com/opensource/ucl/

Copyright (C) 1996-2004 Markus Franz Xaver Johannes Oberhumer
http://www.oberhumer.com/opensource/ucl/

pack2e.exe: using block-size of 4194304 bytes
pack2e.exe: algorithm NRV2E-99/10, compressed 318756 into 239150 bytes
../../bin/packwrap: line 3: /cygdrive/c/Users/<WINDOWS_USER>/Downloads/agtools/bin/packwrap.exe: Accessing a corrupted shared library
make: *** [Makefile:210: isoscrl0.pct] Error 126

then another error on the next make

Code: Select all

UCL data compression library (v1.03, Jul 20 2004).
Copyright (C) 1996-2004 Markus Franz Xaver Johannes Oberhumer
http://www.oberhumer.com/opensource/ucl/

pack2e.exe: using block-size of 4194304 bytes
pack2e.exe: algorithm NRV2E-99/10, compressed 318756 into 238597 bytes
../../bin/packwrap: line 3: /cygdrive/c/Users/<WINDOWS_USER>/Downloads/agtools/bin/packwrap.exe: Accessing a corrupted shared library
make: *** [Makefile:210: isoscrl1.pct] Error 126 

until it finally completes and creates the TOS and PRG file.

Weird thing is , when I run a make clean and do make again, these errors no longer happen.

When I then start Hatari (finally found how to use debug on Windows)

hatari -W -D --trace os_base isoscrol.tos

Code: Select all

________________________________________

EmuTOS Version:     0.9.10
CPU type:           M68000
Machine:            Atari STe
ST-RAM:             4 MB
GEMDOS drives:      ABC
Boot time:          2018/12/23 00:00:00
________________________________________

Hold <Control> to skip AUTO/ACC
Hold <Alternate> to skip HDD boot
Press key 'X' to boot from X:
Press <Esc> to run an early console

   Hold <Shift> to pause this screen
GEMDOS 0x4B Pexec(7, 0x7, 0xf4c, 0x2084) at PC 0xE3A062
GEMDOS 0x4B Pexec(0, "\AUTO\ISOSCROL.PRG", [0]"", 0x2084) at PC 0xE3A062
GEMDOS 0x3D Fopen("\AUTO\ISOSCROL.PRG", read-only) at PC=0xFA00FC
-> FD 64 (read-only -> read-only)
GEMDOS 0x4B Pexec(7, 0x5, 0xe0111e, 0x2084) at PC 0xFA018C
GEMDOS 0x3E Fclose(64) at PC 0xFA0256
[A]tari [G]ame [T]ools / dml 2017
Isometric scroll (STE)
machine: STE
press space...
loading tiles...
GEMDOS 0x3D Fopen("isoscrl0.pct", read-only) at PC=0x14044
-> FD 64 (read-only -> read-only)
GEMDOS 0x3D Fopen("isoscrl0.pct", read-only) at PC=0x14044
-> FD 65 (read-only -> read-only)

and then it hangs , nothing further happens

[Eero Tamminen]

For hangs, it's best to trace all OS calls (--trace os_all) to see whether last one might be the culprit.

Once it's hanged, you could enable profiling ("profile on") in debugger and continue for a while before invoking debugger again and using "profile addresses" to see what code addresses / instructions it's continuing to execute. From that you could see if it's e.g. looping waiting for some register value to change, and in general see from instruction call count changes how much of each branches are being executed.

If program crashes instead of just looping without proceeding, set breakpoint for the crash (exception etc) and enable enough CPU history ("history cpu 200") to investigate (when the breakpoint gets hit) how it arrived there ("history 200").

[dml]

Thanks for all the info gathered on this issue! I should be able to figure out what is going on now. It does look like a failure in the build process.

One thing I'd point out (from the log above) is that Windows can have some issues with user permissions where Cygwin directories overlap with protected directories. I see that you are building the agtools project from 'Downloads', which is a managed Windows user directory, and it is being written via a Cygwin path:

/cygdrive/c/Users/<WINDOWS_USER>/Downloads/agtools

While I'm not sure it is the cause, it could be that one of the tools is hitting Win permissions while trying to write files.

Try moving the agtools directory to a non-managed folder e.g. c:\projects, with no permission restrictions and see if the error goes away.

In any case I'll look into it and see if the problem is in the toolchain itself.

[lastic]

I tried moving the agtools folder to C:\jac for example but same result.

Code: Select all

../../bin/packwrap: line 3: /cygdrive/c/Users/<WINDOWS_USER>/Downloads/agtools/bin/packwrap.exe: Accessing a corrupted shared library

I think the fault lies here, but strange enough all other demos build fine (but they don't use packwrap upon further inspection) .
Clearly it must be something with my tools or Windows configuration if it works for everybody else.

When I try to start packwrap.exe manually from a CMD prompt I get

Code: Select all

C:\Users\<WINDOWS_USER>\Downloads\agtools\bin>packwrap.exe
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

C:\Users\<WINDOWS_USER>\Downloads\agtools\bin>packwrap.exe --help
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

C:\Users\<WINDOWS_USER>\Downloads\agtools\bin>pack2e.exe

UCL data compression library (v1.03, Jul 20 2004).
Copyright (C) 1996-2004 Markus Franz Xaver Johannes Oberhumer
http://www.oberhumer.com/opensource/ucl/

usage:
  pack2e.exe [options] input-file output-file      (compress)

I've googled it and the side-by-side error in EventViewer references that I'm missing

Code: Select all

Activation context generation failed for "C:\jac\agtools\bin\packwrap.exe". Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.6195" could not be found. Please use sxstrace.exe for detailed diagnosis.

so I think I found my culprit, I have VC++ 2010 x86 installed on my 64-bit Windows 10.

One last request , could you provide me a complete isoscrol folder with a compiled isoscrol.TOS and PRG ,so that I can compare it with my compiled version ?

[dml]

Well I think that explains it pretty well - the packwrap tool was probably built against VC2010 debug runtime and I didn't notice.

This is one tool I had lost the source for and is not in the repo - but I think I have found it now so I should be able to rebuild it and add to the repo.

Thanks again!