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

[TheNameOfTheGame]

Found a possible problem when running the "parallax" example under hatari.

It starts fine and looks fantastic:

parallax.png

Then after 2-3 minutes the screen gets messed up (the problem is repeatable):

parallax_error.png

[Playmobil]

Edit assets_com.sh and remove the line that sets AGTROOT. Then try again. The docker image sets this for you.

It was the 1st thing I do with the file "assets_com.sh"
set -e, is before the line about AGTROOT...

The image defaults to running make but you can also run other commands too such as -
docker run -v ${PWD}:/agt-tools/build -it prog99/agt-tools make clean
or if you fancy a poke around in the shell
docker run -v ${PWD}:/agt-tools/build -it prog99/agt-tools bash
etc...

Will try this !

Just refreshing the image with the latest changes.

Not sure if I understand well... You have done a new Docker image of AGT-Tools ?

[prog99]

Just refreshing the image with the latest changes.

Not sure if I understand well... You have done a new Docker image of AGT-Tools ?

Yes, its just built and pushed to docker hub. I've tested it on giantsprite and it worked fine.
Oh and to avoid confusing Doug, lets keep my build to our PMs until its stable. At least I now know the windows syntax.

[prog99]

Found a possible problem when running the "parallax" example under hatari.

It starts fine and looks fantastic:

parallax.png


Then after 2-3 minutes the screen gets messed up (the problem is repeatable):

parallax_error.png

Yes, can reproduce on a fresh build on hatari macOS.(your screenshots are steem)

Code: Select all

mike@Mikes-MacBook-Pro ~ $ hatari 
INFO : Hatari v2.4.1, compiled on:  Aug 18 2022, 09:48:54
TODO : Support for Hatari window reparenting not built in
INFO : Inserted disk '/Users/mike/Documents/Untitled.st' to drive A:.
INFO : GEMDOS HDD emulation, C: <-> /Users/mike/Documents/ST.
WARN : Address Error reading at address $1ceb6d, PC=$c30a addr_e3=c30a op_e3=201d

[dml]

The problem with the parallax sample is a bug in the sample itself - I'm aware of it, just haven't got around to looking at it. It is tripping an engine safety check, which is the pattern you see on the screen. Probably a scrolling range issue.

[dml]

There are definitely still some weird issues in some of the sprite clipping paths, but only in very specific conditions, which apparently don't disturb most of the samples (despite how varied they are)... I haven't figured it out yet but when I'm sure it has been resolved I'll post an update and hopefully that will be it settled for a while (and so, dockers can be refreshed and hopefully stable for a bit!)

[dml]

Ok I found the issue and fixed it. I'll commit the fix today sometime - but it might be wise to hold off with docker business until I have more time to test all the samples more thorougly, including the private user projects and some of my own demos I haven't published yet. It's *probably* fine now but the code is fairly complex and deserves a bit more testing...

[Playmobil]

Not sure if I understand well... You have done a new Docker image of AGT-Tools ?

Yes, its just built and pushed to docker hub. I've tested it on giantsprite and it worked fine.
...

OK, thanks, I will try soon !

[dml]

I went through it all again and checked all the samples, fixed more bugs, confirmed its all working properly with the non-public test projects.

The parallax sample bug is fixed, it shouldn't lock up anymore.

The abreed demo has been disk-swapped so the split-screen/coop version is now on disk1, the standard version is on disk2.

The sprtest sample has been modded to solid-fill sprites that switch from guard mode to clipping mode. This debug feature is controlled by a Makefile define/switch and can be enabled in other samples the same way.

The bosscore demo has been updated to use a faster sprite method for the giant boss as it was using the older slab primitive and it was dropping frames sometimes. Since the demo is also a sample showing how to set up slabs and custom clearing shapes, i left the old version in there and it can be switched over at build time with a define at the top of the source.

The rest is mainly bug and consistency fixes.

Should be safe to dockerize this version now

[TheNameOfTheGame]

Thanks for the update. All the examples compiled here on Linux except for sprtest.
Had this error:

Code: Select all

configured AGT native tools @ ../../scripts/../bin/Linux/x86_64
note: aliased [lzsa] to [lzs2]
wrapping assets/1ems.ems_ with [lzs2]
../../scripts/pack.sh: line 129: ../../scripts/../bin/Linux/x86_64/lzsa: No such file or directory
PackWrap: compressed asset wrapper for AGT : dml/2022
error: could not stat packed file: assets/1ems.ems_.lzs2
wrapping failed with exit code 1.
make: *** [Makefile:203: cache/assets_common.dep] Error 1

Changed the end of assets_com.sh for sprtest to:

Code: Select all

#
# pack the copies
#

${PACK} ${OUT}/1ems.ems_  lz77
${PACK} ${OUT}/2emx.emx_  lz77
${PACK} ${OUT}/3emh.emh_  lz77
${PACK} ${OUT}/4slab.sls_ lz77
${PACK} ${OUT}/4slab.slr_ lz77

and then it finished. Am I supposed to have lzsa on Linux? I only see lz77.

[dml]

Oh - you can change it to lz77 and it should work. I'll do that here before the next commit. lzsa is more representative of what you'd probably use though for compressed assets, unless speed was the priority.

BTW it's not actually using those compressed assets in the sample, its just previewing what the compression ratios would look like if you did use them. The other demos etc. do actually compress their assets though.

I didn't want to ship linux binaries and especially didn't want to duplicate the lzsa git repo in the AGT project - you can grab it from github and compile yourself but it's difficult to distribute with AGT 'out of the box' for Linux (not least because there are different distros).

[prog99]

Just rebuilt my docker image against Doug's latest pushes.
I've also made the default action to automagically strip setting AGTTOOLS from Makefile & *.sh. It'll also run dos2unix on any .sh files too as windows carriage returns cause bash to work unpredictably.

[Playmobil]

Just rebuilt my docker image against Doug's latest pushes.
I've also made the default action to automagically strip setting AGTTOOLS from Makefile & *.sh. It'll also run dos2unix on any .sh files too as windows carriage returns cause bash to work unpredictably.

Thank you prog99 !
I will try as soon as possible !

[Playmobil]

Just to say the latest Docker image from prog99, work fine under Windows10, and I'm able to build all stuff provided on the AGT bitbucket...
I'm happy !
Now, need to learn & learn & learn all specifics commands from the AGT's engine...

Thanks @dml & thanks @prog99

[Nyh]

I forgot to add - arjbeta.exe is one of two tools needed to pack arj assets. The second tool parses the arj index and extracts the raw blocks for the decompressor. So it's not enough to just build the correct ARJ on Linux unfortunately. Still, it seems like a solvable problem if there is a need.

Hans Wessels (Mr Ni!) did the real hard work on ARJ - not sure if he is still around here reading/posting but if anyone would know the requirements it is Hans.

The MC68000 decoder for ARJ can decode all types of ARJ compressed data. ARJ m1, m2 and m3 have the same format as ARJBETA m7, the original ARJ has a dictionary size of les than 32 k, ARJBETA m7 uses a 64 kB dictionary. But there is stil a difference in packing ratio when you compare ARJ -m1 -jm with ARJBETA -m1. Archives created with ARJBETA -m1 are fully compatible with ARJ -m1 but have a better packing ratio because it uses the lz77 engine in ARJBETA is beter. Instead of ARJ you can also use the lh7 method of LHA, this is fully compatible with ARJBETA m7, the decoder can decompress them, but the packing ratio is not as good as the one in ARJBETA.

Hans

[Nyh]

duplicate deleted

[dml]

Hi Hans - that's very helpful info. Thanks for filling those details on the 68k decoder and packer compatibility!

[LaceySnr]

Have just orederd an UltraDev cartridge - hoping it kicks my butt into gear to get going with AGT again! The idea of having a second screen for debug output is awesome. I'm half thinking it'd be cool to have something like an imGui lite, to format the output into boxes for various watch expresssesions etc. but imagine that'd be a bit too intensive in terms of CPU usage

[mikro]

it'd be cool to have something like an imGui lite, to format the output into boxes for various watch expresssesions etc. but imagine that'd be a bit too intensive in terms of CPU usage

Indeed. I think the closest one could be the SuperVidel's Blitter, that could manage to render an additional layer with very little overhead.

Ideally, if SuperVidel supported true alpha channel, that would be then a whole different story.

When working on Falcon projects, I usually use Aranym's natfeat debug output, for tricky scenarios then Hatari and its console output (which is usable also for ST/STE development).

[Eero Tamminen]

When working on Falcon projects, I usually use Aranym's natfeat debug output, for tricky scenarios then Hatari and its console output (which is usable also for ST/STE development).

I assume you know these, so this is just a comment to others...

While Aranym is nice and fast, it's more like an Atari clone than Falcon, as it emulates 040, does no cache emulation, and I do not know of any real program that would work with its (threaded) DSP emulation.

Hatari offers NatFeats debug output too, and has also example code for using NatFeats from Atari programs: https://git.tuxfamily.org/hatari/hatari ... readme.txt

[LaceySnr]

Saw an earlier post this error:

Code: Select all

build/aglib_ste.a(pflib.o):pflib.o:(.text+0x6d2e): undefined reference to `_drawcontext'

I can't build any of the demos/examples at the moment with a similar error, though it appears

Code: Select all

_drawcontext

got renamed to

Code: Select all

_g_drawcontext

. I can see it's a globla shared thing, and can see why pflib can't find it (it's in spr_clear.s), but haven't worked out a way for it to include that then doesn't cause duplicate symbol conflicts instead.

Anyone know what I'm missing to build these demos etc. on the latest commit?

[dml]

Hi Matt - I saw some of recent the PRs etc. on bitbucket but I've been really busy to look at any of this properly. I will take a closer look when I get a bit more time. But maybe a clue meantime...

IIRC the drawcontext stuff was changed to allow the game code to have multiple contexts (since there are now multiple viewports and each one can have a different clipping window, stride etc). The samples were fixed to cope with this. However any existing projects not in the repo would need updated in a similar way. I forget the exact details but I'll post when I get a chance to figure it out.

[LaceySnr]

No worries - figured you were quite busy hence just wondering if someone had found a solution in general. Were those samples on a branch or something because I can't build the ones freshly cloned from the repo. Started trying to get my head around it last night but had to tap out to get some sleep.

[AnthonyJ]

Saw an earlier post this error:

Code: Select all

build/aglib_ste.a(pflib.o):pflib.o:(.text+0x6d2e): undefined reference to `_drawcontext'

I can't build any of the demos/examples at the moment with a similar error

Pretty sure you need to do a clean as you have stale object files from a previous build. See the dml's reply last time someone raised this same linker error:

The missing symbol is something that was removed from the engine, but added to the samples. I'm pretty sure the changes made it into the repo as I have none outstanding - but I'll double check it.

Try cleaning the project fully to get it to rebuild all the sample & engine code again. The sprites also need rebuilt because the version info changed.

Code: Select all

> make clean-all && make disk1

[LaceySnr]

Yeah I tried that but it didn't seem to fix it - will play around some more tonight. Been a long time since I touched this stuff but keen to get back into something!