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

[dml]

Is this Bad Mood or something else?

Something else, not ready to show yet. I'll return to it before long with any luck. I'll probably open a thread here when I do...

[dml]

[UPDATE]

An important new feature just went in.

Amiga has Copper. AGT now has Nickel.

Nickel provides similar functionality to Copper, in the sense that it allows you to reprogram the display (or arbitrary hardware registers) using a series of commands organized something like a display-list.

You can either do this once, to set up a custom display mode before the game mainloop (e.g. split-screen), or you can reconfigure Nickel each game refresh, allowing you to move things around including viewports & palette changes.

Nickel uses code-generation at runtime to implement the HW side. This incurs a small cost each time commands are loaded into Nickel (similar to the cost of drawing one very small sprite).


Obviously this system is limited by STE HW capabilities which is definitely not 1:1 with Amiga - and operating at a slightly higher level than pure HW ports - but it does make some quite advanced STE capabilities VERY EASY to use within game code. It's the ease with which you can mess with the display which makes it powerful IMO. I think it makes up for quite a lot, and should allow AGT projects to do some things you'd normally not see in ST games.


There is a bit more to Nickel than just generating 'rasters' - it supports display port binding/remapping and some other things which are more easily demonstrated via new demos/samples.

I have updated the two demos using spliit-screen and multiple viewports to use Nickel instead of the pre-baked modes they relied on until now - and will be re-implementing the existing display configs as variations on default Nickel configs. Only the base 320x200 and full-size, 272-line modes will sidestep Nickel for simplicity. All other modes (e.g. 320x240) will be programmed via Nickel internally - or by the user from the game code for custom displays.

I'm working on some new samples to show what can be done with this component. This will probably take another week or more due to lack of time but they are on the way...

[TheNameOfTheGame]

Sounds really cool. Looking forward to the new samples.

[TheNameOfTheGame]

Trying to pull in the new changes with "git pull" but I'm getting an error:

Code: Select all

remote: Counting objects: 115, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 115 (delta 92), reused 100 (delta 81)
Receiving objects: 100% (115/115), 119.00 KiB | 1.14 MiB/s, done.
Resolving deltas: 100% (92/92), completed with 72 local objects.
From https://bitbucket.org/d_m_l/agtools
   e9aeaf3..0c0fca5  master     -> origin/master
Updating e9aeaf3..0c0fca5
error: Your local changes to the following files would be overwritten by merge:
	tutorials/tutor2/chunky8.ccp
	tutorials/tutor2/chunky8.ccr
	tutorials/tutor2/chunky8.ccs
Please commit your changes or stash them before you merge.
Aborting

[dml]

Thanks for reporting that - I must have left the PCS command enabled in the ./makedata.sh so it has generated those 3 files locally and they are also trying to update from the repo as well. You can just zap or reset the local copies of those 3 files and try pulling again. I'll fix the script soon.

[TheNameOfTheGame]

Ok, thanks for the clarification. "git pull" works now after deleting the files. Also, are the two Nickel demos you updated in the repo now or is that what will be added in the future? I pulled the whole project in again and thought the abreed demo had the split screen but it is full screen.

[dml]

Also, are the two Nickel demos you updated in the repo now or is that what will be added in the future? I pulled the whole project in again and thought the abreed demo had the split screen but it is full screen.

Ah - yep. The split-screen one is built as 'coop.prg' into the same auto folder, but it never gets a chance to run because the other one doesn't exit I was in kinda a hurry when I added this demo. If you delete 'abreed.prg' after building, you can boot it up that way.

Alternatively, delete target 'demo1' from the list of targets in the Makefile, leaving only 'demo2'. It will then build only 'coop.prg'.

I'll split them up soon so you can build them separately.

The parallax demo isn't in the repo yet but its basically done so I'll add it sometime this evening.

[Eero Tamminen]

Amiga has Copper. AGT now has Nickel.

That's pure Gold, or err... Cupronickel! Used to propel things forward: https://en.wikipedia.org/wiki/Cupronickel

[calimero]

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

Cyprian mention some interesting tidbits about Falcon, TT, ST, Jaguar... at https://www.atari-forum.com/viewtopic.p ... 50#p408050

Maybe it will be interesting for others also...

or splitting the screen in different bit depths, for instance 8bp in one part and TrueColor in another.

wow, wow, wow!! Is it possible to get this on Falcon: "8bp in one part and TrueColor in another"?? Just like on Amiga?


btw
Eero, you are only person that work on Hatari or there are more developers?

[dml]

Also, are the two Nickel demos you updated in the repo now or is that what will be added in the future?

...and I have now added examples/parallax to the repo.

As with the other samples, you need to run ./makedata.sh at some point to build the assets.

[TheNameOfTheGame]

Also, are the two Nickel demos you updated in the repo now or is that what will be added in the future?

...and I have now added examples/parallax to the repo.

As with the other samples, you need to run ./makedata.sh at some point to build the assets.

Nice scrolling in that example. I did get a warning running ./makedata.sh. Is it normal?

Code: Select all

[A]tari [G]ame [T]ools: playfield/sprite/slab cutter v0.461 / dml
autocut key colour from rgb: r(ff):g(ff):b(0):
key colour from rgb: r(ff):g(0):b(ff):
002c:fixme:ver:GetCurrentPackageId (0x33fab0 (nil)): stub
warning: can't open this image

[dml]

Nice scrolling in that example. I did get a warning running ./makedata.sh. Is it normal?

Bah, seems I forgot to add the sprite sheet. Now added...

You can re-grab from GIT and run ./makedata again. You should get sprites this time.


(I don't know why that specific and obscure error was shown instead of a usual file open error. Another VS runtime libs issue probably - something I don't see here. But it failed due to a missing PNG).

[calimero]

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?

If a may repeat this question! : Videl can split the display into different screen modes?

Just like on Amiga?

[dml]

If a may repeat this question! : Videl can split the display into different screen modes?

Yes.

Just like on Amiga?

They're not really comparable re: how they work - but yes the Falcon can change its display registers mid-frame. You can mix displaymodes on one screen.

It is far better supported in RGB mode. VGA timing is much more restrictive but it is still possible to do it, with some care.

[Xerus]

AGT now has Nickel.

Nickel provides similar functionality to Copper, in the sense that it allows you to reprogram the display (or arbitrary hardware registers) using a series of commands organized something like a display-list.

This engine is becoming more and more impressive, bravo.
The development studios of the great era would have dreamed of having AGT!

[joska]

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.

The lack of good emulation should not stop us from developing for the Falcon. The current state of Hatari allows you to use stuff like paint programs, trackers (to some degree) and other applications but games is out of the question due to the limited Videl emulation. So the audience simply isn't there. Atleast not yet.

But I can appreciate the practical side of emulation, even when it's not perfect.

Perhaps not everyone wants to support emulation, but it is a decision they'd need to make early in their project.

You should never have to support emulation. It's the emulator that has to support the features and behaviour of the system it attempts to emulate.

[mrbombermillzy]

I completely agree with Jo here.

Although I really do get where you are coming from regarding a wide as possible user base, Doug.

However, if people are making AAA games on the F030 with AGT, Im sure there will be extra efforts to get the emulation improved ASAP.

[Eero Tamminen]

The lack of good emulation should not stop us from developing for the Falcon. The current state of Hatari allows you to use stuff like paint programs, trackers (to some degree) and other applications but games is out of the question due to the limited Videl emulation.

There are only few Falcon games where Hatari's incomplete Videl emulation is a problem. Most work fine: https://hatari.tuxfamily.org/doc/compat ... lcon_games

[joska]

If Hatari supported actual refresh rates it would work much better. Now all screenmodes are fixed at 50Hz, which messes up timing and tempo in most games.

[dml]

Another parallax example:

https://youtu.be/QxKVdhiuEic

I'll be short on time to finish this off - but it should already show use of parallax FX in a more practical, less contrived situation.

This uses Nickel BTW.

I probably won't add it to the repo until I get a chance to clean it up a bit and add some missing pieces.

[junosix]

WOW!

[TheNameOfTheGame]

Very Nice!

[Eero Tamminen]

If Hatari supported actual refresh rates it would work much better. Now all screenmodes are fixed at 50Hz, which messes up timing and tempo in most games.

Please add a list of Falcon games you know to need 60Hz VGA to the atari-forum Hatari area (or send it to Hatari mailing list), so that Hatari compatibility list can be updated.

[masteries]

Another parallax example:

https://youtu.be/QxKVdhiuEic

I'll be short on time to finish this off - but it should already show use of parallax FX in a more practical, less contrived situation.

This uses Nickel BTW.

I probably won't add it to the repo until I get a chance to clean it up a bit and add some missing pieces.

WOW Douglas! Also... the fade in of second layer is more than awesome!


P.S. Also, can anyone test if the Run & Gun published demo can be executed on a Falcon? I don´t have a Falcon to test the progress,

[dml]

WOW Douglas! Also... the fade in of second layer is more than awesome!

The secret sauce here is hidden in the bouncy lasers. It's not sprites and its not lines! The backgrounds here are 2-layer, 8x8 character maps.

I don't know how the arcade did it, but I expect similar. Some kind of character map overlay.

Both layers can be 16 colours (the R-Type parallax layer only needs 4 though).

There are other tricks here but I think you will know them

P.S. Also, can anyone test if the Run & Gun published demo can be executed on a Falcon? I don´t have a Falcon to test the progress,

Unfortunately I don't have mine set up just now but someone else here might.