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

[prog99]

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.

Hi Doug, thats been fixed for a while now, some very clever folk at codeweavers figured it out.

Wondering actually if it would be better to wrap it all into a container and thus remove any platform dependencies. I've the knowledge from my day job but not the time to do so unfortunately.

[dml]

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

Your efforts turned out to be quite useful Thanks!

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

It's not actually corruption - the stuff in the examples/ dir isn't meant to be pretty but instructive. The map examples show how to set up different sized tilemaps (8x8, 16x16) with different layer counts and then make live edits to them in rows/columns. So the corruption is just how the tilemap edits look.

e.g. in the 16x16x2layer example some of the edits can be seen passing underneath tiles in the top layer.


In other words - those projects look like they are working too.

[dml]

Hi Doug, thats been fixed for a while now, some very clever folk at codeweavers figured it out.

Ok I'll definitely check that out.

Wondering actually if it would be better to wrap it all into a container and thus remove any platform dependencies. I've the knowledge from my day job but not the time to do so unfortunately.

I've been avoiding this because I didn't want to create extra inertia for uptake, instead letting people use the environment they want. But it might end up being the pragmatic thing to do for the build tools if it leads to less breakage. I'm still thinking about this one.

The most important thing for me isn't really the ability to build the samples etc. (as important as it is!) but the ability for users to work with their own graphics, map & audio tools for the art assets. For me these are mostly on Windows but they could be on Mac or Linux for other users. Having to swap environments constantly isn't great when working on a game so its best for a user if everything is seated in host environment.

[TheNameOfTheGame]

The tutorials all compile under Linux after my changes to the rmac files.

Well, tutor6 initially had some errors with "make". I ran "make clean" and then "make" again and they went away, but then I had to update one more file in the rmac/ste directory to change the "rmac/" instances to "../../rmac/" and then it compiled ok.

[dml]

[UPDATE]

So I have committed some changes today which resolve most of the problems for:

- Cygwin
- WSL
- MacOS (albeit, using a subset of native binaries for now, avoiding Wine)

I cannot test on Linux but it should be close. Hopefully it works. Linux version still uses Wine.

I have only tested a few of the samples. Some might still be broken (perhaps if using the less common tools) but I'll fix them in a follow-up commit if so.


IMPORTANT:

All targets must still export the $AGTROOT env var to point at the 'agtools' root dir. Otherwise there will be build errors.

($AGTBIN is not required anymore)


MacOS:

I have only supplied native builds of agtcut & rmac. These are the most important tools to get most of the samples working.

A native build of pcs will follow soon (most of the sample makedata.sh scripts have it disabled anyway, with the generated palettes already cached in the repo).

upx, pack2e/packwrap, cincbin however are missing. Packer features can't be used on MacOS until this is resolved.

[dml]

The tutorials all compile under Linux after my changes to the rmac files.

i am wondering if most of the path issues were caused by the AGTROOT env var being undefined? It needs to be exported in order that projects (both inside and outside of the agtools dir) can set the assembler include paths for some of the engine .s sourcefiles. It is also now needed for locating the $AGTROOT/bin dir.

Anyway I will try to get a Linux env set up soon so I can see what is going on. However if you are able to stash your edits temporarily (or create a new working dir) and try the latest version with AGTROOT set, I would be interested to know if it behaves any better now on Linux. It should at least no longer show errors on wslpath commands etc.

[dml]

I'm setting up a new Linux VM so I should be able to do some testing/fixes by the weekend

[TheNameOfTheGame]

Ok, I backup my agtools directory and pulled the new version.

Initially things looked good. I had set AGTROOT with:

Code: Select all

export AGTROOT="$HOME/Projects/agtools"

and all the examples compiled with no errors and no changes needed to the rmac files. Tutorials compiled also, with the caveat that tutor6 still had errors until I did a "make clean"

However, tyring to run these in steem results in 3 bombs. Same thing on all examples and tutorials. Each program prints the first line like below then crashes with 3 bombs back to desktop. The examples and tutorials created using my original build directory still work fine in steem.

Code: Select all

printf("[A]tari [G]ame [T]ools / dml 2017\n");

[dml]

Ok, interesting (and weird). Thanks for trying it. I should be able to make progress on this soon.

[dml]

I think this new issue (3 bombs) is not Linux-specific, but a consequence of me updating the Windows assembler version so it matches the Mac version, in the last commit. I see the same now under Cygwin & WSL too.

I think I know what it might be, but trying to confirm...

[dml]

That should be fixed now, I think. At least it resolved the 3 bombs in the giantsprites/ sample. Haven't had time to check the rest.

[dml]

I just tested a build of 'giantsprites' on a clean Ubuntu VM (after installing mint-cross-tools, git, make, wine etc...) and it does seem to build ok. The makedata.sh also works correctly.

I don't have an emulator in the VM - but with the previous issue fixed, the linked .prg should be ok.

[TheNameOfTheGame]

Tested all the examples and tutorials under Linux with the new changes and everything compiles and runs under steem. Thanks for the fixes.

P.S. still had to "make clean" tutorial 6 before i could run "make".

[dml]

P.S. still had to "make clean" tutorial 6 before i could run "make".

Thanks!

There must be a stale asset in the repo. I'll fix that next chance I get.

[dml]

P.S. still had to "make clean" tutorial 6 before i could run "make".

I don't see any stale assets in the tutor6 dir. I suspect the problem is caused by the Makefile referring to additional targets which don't exist yet.

Only tutor6a is in the repo (tutor6b,tutor6c aren't finished yet) but there are targets for all 3. I'll fix this as part of the next commit, until the missing tutorials are added.

[dml]

[UPDATE]

Recently pushed some collected changes which include:

- support for more than one game viewport (display ports not yet configurable - to follow, soon)
- simplifying the use of buffers/fields for all of the most common scenarios. it was overly complicated.
- can mix single & dual-field sprites on same playfield
- can force dual-field sprite drawing (for dual-field generated sprites) on single-field backgrounds, using a new playfield attribute.
- added new 'examples/startpoint' sample which intended for starting off new projects easily

The changes for viewport & dual-field settings are breaking changes. They are simple to correct but do need to be corrected in the game source. This has been necessary to support multiple views. Refer to diffs to see what has been done to the demos (or reach out to me if you need help).

The most important change is the need to call EntitySelectViewport(pviewport) at least once with a viewport entity before any entity related engine passes are used. This can be done immediately after creating a viewport. If multiple viewports are used, this function will select which one is active for subsequent passes. This will be exampled in a new project to be added soon...

All of the demos/samples/tutorials updated accordingly. Some fixes/improvements to various samples (e.g. exploding text in tutor5c was just wrong).

One more sample will be added soon which shows 3 different ways to define spritesheet cutting commands (commandline, scripted, auto-guided). It should clarify the differences between them so you can pick the easiest method for each job.

I noticed an agtcut slab-cutting bug while running ./makedata.sh for demos/bosscore. Until that is fixed i committed pre-built slab assets to the repo and disabled the cut command for these.

[EvilFranky]

Been meaning to ask this for a while Doug, is there scope for a Falcon specific version of AGT?

I'm assuming the same optimized Blitter routines could be applied to the Falcon also, but with the added bonus of 8bpp?

Curious to see what the Falcon's additional grunt could bring

[dml]

Been meaning to ask this for a while Doug, is there scope for a Falcon specific version of AGT?

I was going to write something about this recently, but then I remembered that some of the features in the STE version (and about to materialise very soon - this week) will have no emulation support on the Falcon. So it would have to be developed on HW only, and run on HW only. Not ideal.

I'm assuming the same optimized Blitter routines could be applied to the Falcon also, but with the added bonus of 8bpp?

Yes. The Falcon is probably even better at it, in some ways. The 68k can't run concurrently (much!) with BLiT commands while the 030 can. And with 8bpl you can do more effects of course. And you can run more complex game logic with the extra CPU cycles.

Curious to see what the Falcon's additional grunt could bring

I want to get the STE version of AGT rounded off to the point where it isn't missing anything really important.

I will then probably return to a different F030 work-in-progress for a bit. Following that, I might look again at F030 AGT, and what can be done within the scope of current emulation (or not).

[dhedberg]

I was going to write something about this recently, but then I remembered that some of the features in the STE version (and about to materialise very soon - this week) will have no emulation support on the Falcon. So it would have to be developed on HW only, and run on HW only. Not ideal.

Yes, it's a pity that the Videl is still not emulated more properly in Hatari. Multiple viewports would not be emulated, neither would palette switching to achieve more colors, or splitting the screen in different bit depths, for instance 8bp in one part and TrueColor in another. There's not even a 60Hz VGA mode. Only 50Hz. So the Falcon video emulation is still fairly crippled unfortunately. But you know all this I'm sure.

[EvilFranky]

Thanks for the response Doug, exciting to hear there are some initial plans for a Falcon AGT...and some other secret Falcon development

Yes, it's a pity that the Videl is still not emulated more properly in Hatari. Multiple viewports would not be emulated, neither would palette switching to achieve more colors, or splitting the screen in different bit depths, for instance 8bp in one part and TrueColor in another. There's not even a 60Hz VGA mode. Only 50Hz. So the Falcon video emulation is still fairly crippled unfortunately. But you know all this I'm sure.

Videl can split the display into different screen modes?

[dml]

Yes, it's a pity that the Videl is still not emulated more properly in Hatari. Multiple viewports would not be emulated, neither would palette switching to achieve more colors, or splitting the screen in different bit depths, for instance 8bp in one part and TrueColor in another. There's not even a 60Hz VGA mode. Only 50Hz. So the Falcon video emulation is still fairly crippled unfortunately. But you know all this I'm sure.

Daniel, yes. That's exactly what I was thinking - while we could see all of the basics working on F030, some really important stuff would need to be left out, or provided on the basis that it just won't emulate if it gets used.

I suppose this affects anyone thinking of making a 2D game for F030 - same issues. But uptake of AGT for F030 is probably not going to be significant to begin (!) with and anyone considering it would be thinking twice about investing time when we can't necessarily use all of the available features on the machine, or using those features excludes a lot of people from trying the game.

Maybe forging ahead and using Videl features is a good way to get them supported by Hatari But emulating that stuff won't be easy so I expect it just isn't going to happen any time soon, if ever.

[joska]

So it would have to be developed on HW only, and run on HW only. Not ideal.

Developing on real hardware is always more fun than using an emulator IMO. For cross-development you can use Parcp-USB and push the compiled binaries directly to the Falcon for testing as a part of your build.

[mrbombermillzy]

Um, Im currently making a display system for TT that is definitely not emulated.

Please dont let lack of emulation stop your creative juices Doug!

There must still be a fair number of Falcons out in the wild being used, surely?

[dml]

I can & do develop on real HW, but it is less convenient. I can only do it in one place, not on the move (has been often). Sometimes I only spend half an hour working on code in between other things so I need to be efficient with that time. Currently the Falcon is packed while that desk space is given to the STE.

Development aside, the other concern is that any user of AGT working on a F030 game probably wants as wide an audience as possible for their efforts. Perhaps not everyone wants to support emulation, but it is a decision they'd need to make early in their project.

But I do appreciate the feedback/input - these opinions will help me decide what to do re: AGT on F030.

[CiH]

I will then probably return to a different F030 work-in-progress for a bit.

Is this Bad Mood or something else?

Just asking because I'm a nosy sod.