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

[I_am_I]

@masteries, yes it works on my stock falcon, with some graphical glitches though.
It looks like some sprites aren't cleared correctly, doesn't seem like a hard one to fix. I'll send you some screenshots tomorrow, if you want.
Apart from that, it moves and sounds fine.
Amazing stuff, BTW!

[masteries]

@masteries, yes it works on my stock falcon, with some graphical glitches though.
It looks like some sprites aren't cleared correctly, doesn't seem like a hard one to fix. I'll send you some screenshots tomorrow, if you want.
Apart from that, it moves and sounds fine.
Amazing stuff, BTW!

@I_am_I Thank you very much! These are good news, that Falcon users can benefit from STE oriented games too,

The published demo is obsolete now! hehe I am preparing real good things,

yesterday I was implementing map walkways, this concept is not tile-based, its based on lines drawn over the map in order to provide great freedom; but only the useful information is stored, around 2KB.

[BlankVector]

Another parallax example:

https://youtu.be/QxKVdhiuEic

Wow, that's completely amazing! Go ahead. People will be able to make great new games with such tools.

[dml]

Wow, that's completely amazing! Go ahead. People will be able to make great new games with such tools.

Many thanks! I hope it can boot up a few more game projects on the STE.


Aside from some finishing touches on this sample, I do plan to do one more of these to show off additional playfield features.

Finding (and hand-repairing!) the gfx assets does take up a *lot* of time however. This takes longer than the demos take to write.

When I have a little more time I will work on improvements for very large sprites / foreground objects among other things.

But before that, I must catch up on a few important requests from Masteries re: Metal Slug

[dml]

yesterday I was implementing map walkways, this concept is not tile-based, its based on lines drawn over the map in order to provide great freedom; but only the useful information is stored, around 2KB.

This is really cool. I remember doing something similar for a platformer prototype I worked on around '92 (STE+Amiga). Project was abandoned, but the collision and path scheme was similar, drawn as a reserved colour onto the map before prep. It allows for smooth slides, ramps etc.

Depending on how you do it, watch out for the thickness of the boundary vs the speed/size of the sprites, especially diagonal vectors vs diagonal lines. Converting the actual paths to a more abstract representation for runtime is a wise move to avoid any pixel-level issues.

[calimero]

What is “character maps”?

I also find laser very impressive over Parallax background!

Btw
on Amiga you need to use dual- playfields to achieve same effect? (Since background and foreground are overlapping, they are not just lines scrolled at different speed)

[calimero]

I wonder if Amigas Project X would be doable on AGT?

https://m.youtube.com/watch?v=_QSqJJgsIZo

E.g for parallax scrolling at the last two minutes of video there is some nice parallax scrolling with color changes and sky at different speeds...

Beside, there is no parallax scroll in entire game but there is like a toon on gfx moving around.

Maybe graphics from second level (frozen planet) could be used to make it parallax scroll (mountain vs ground)? I think that it could look nice in 16 colors. (Btw dml, is there any limit regarding color number in AGT when using parallax scroll? Like 8 + 7 colors on Amiga in dual playfield mode? And how much time parallax in AGT consume e.g. have impact on number of sprites?)

And for the end, there are spritesheets for Project X: http://eab.abime.net/showthread.php?t=20428

[dml]

What is “character maps”?

Just an indexed tilemap. On the 8-bits systems a tilemap used for text/font display was usually referred to as a 'character map' or character-mapped display.

In other words, not raster bitmap, but made up of font characters where the character set could be reprogrammed. Really great for some things, really annoying for other things.

Arcade boards used this for backgrounds and sometimes foreground/sprite graphics. They just had a transparent colour in each character set so you could stack them, within some hardware limits. This was mostly beneficial because the maps could be placed on top of each other, scrolled around at pixel resolution (unlike old 8-bit machines) and offered a kind of compression by reusing tiles often.

on Amiga you need to use dual- playfields to achieve same effect? (Since background and foreground are overlapping, they are not just lines scrolled at different speed)

There are different ways to do these effects. Amiga had dual playfields with limited planes each, or hardware sprites with unlimited height but limited width, stackable. Various games used combinations to make up parallax and other effects. STE doesn't have that HW so we need to use different approach for similar FX.

To our advantage, Amiga could only use those features in limited circumstances because it is generally hard to use features which give you only a few colours at a time, or have some other weird limits. This makes them quite hard to use - a lot of planning and experimenting with art, a lot of trial and error to get best results. Amiga was never an easy system to fully utilise. So most games use them a little, only a few games used them extensively.


STE with AGT is a different situation - you don't have the same graphical power as Amiga with its funny HW features (especially when its mostly hardcoded in 68k, per game) - but you do have 90% of the STE cycles available for graphics, depending on efficiency of your game code, and its super easy to use. So you can get maybe 80% towards Amiga top-class performance, in 1-2 hours of work.



Put simply - I don't think you are going to exactly replicate ProjectX in AGT at 50Hz, with any amount of work. But you could get very very close to it, averaging 35-40Hz, using original graphics, with 1-2 week's work (for a single level!). Quite playable. You could replicate it reasonably closely (compromising on some things) at 50Hz with probably a month's work, if you were crazy-determined.

If you were so determined, it would be better achieved by going straight to 68k and doing it all by hand of course.


I think such effort would be better spent on a decent new game for Atari though. ProjectX looks pretty and early levels are fun enough, but it's another Amiga FX showcase more than anything. Better make a new STE project instead, IMO

I can try to cobble a ProjectX level together for AGT, to see how it looks. But if I do, it will probably be the low-effort version! I'm still trying to finish 3 other demos/samples using it and not quite finding the time to do a good job as it is.

[dml]

(Btw dml, is there any limit regarding color number in AGT when using parallax scroll? Like 8 + 7 colors on Amiga in dual playfield mode? And how much time parallax in AGT consume e.g. have impact on number of sprites?)

None of the AGT demos use colour/bitplane tricks. Everything is 4bpl, 16 colours. This might become more clear in the next sample.


Some demos use dual-field (temporal dithering) to generate a max theoretical 136 colours. But it is typical to achieve maybe 30-60 shades in practice most of the time. I think the max I saw at any time was 120 unique shades. A lot depends on the source material and how it is presented to the palette generator.


The STE can do some bitplane tricks of course but it is time consuming to plan and set up. The developer needs to do that planning. I have poor support for bitplane tricks in AGT just now but as things settle down I may improve on it. Most of the support I do provide is in the form of very powerful palette generation tools, where colours can locked, dodged, plane-reserved or temporal-dithered, all combined in one palette. The drawing side however is still lacking for bitplane tricks.

Nickel can be used to partially reload palettes on different scanlines, which works well if you reserve or lock colours when generating palettes.

Guide:

- dodged or 'protected' colour means the reducer is not permitted to use that colour index even if it is available.

- 'ignored' colour means the reducer pretends it does not exist in the source image (e.g. key/transparent colours, potentially more than one of them).

- 'locked' colour means the reducer can use the colour, but it is predefined by the user. it may take part in temporal dithering but cannot be changed in order to do so.

There is also a means to operate on / generate colours belonging to specific bitplane patterns. So you can do quite a lot with colour organisation. fairly easily. It makes experimentation less difficult/tedious when planning on FX.


The more people who get projects up and running, the more time I am prepared to invest in making it better and adding more special-case features like this. With only a few users, I will focus on making it easy to do the most common things well. To lower the inertia of starting any project. With more users, I can look at supporting more specific things like reduced-bitplane drawing tricks and special Arcade (or Amiga) oriented effects.

[Xerus]

Put simply - I don't think you are going to exactly replicate ProjectX in AGT at 50Hz, with any amount of work. But you could get very very close to it, averaging 35-40Hz, using original graphics, with 1-2 week's work (for a single level!). Quite playable. You could replicate it reasonably closely (compromising on some things) at 50Hz with probably a month's work, if you were crazy-determined.

Project X is mainly a 2 VBL game.
It's 5 bitplanes with sprites, main shot and scrolling in 25 fps.
Only the player's ship and side shots are in 50 fps.

[dml]

Project X is mainly a 2 VBL game.
It's 5 bitplanes with sprites, main shot and scrolling in 25 fps.
Only the player's ship and side shots are in 50 fps.

Scrolling often appears to be 25hz in these games because they use 0.5 pixel scroll to allow for gameplay, otherwise everything advances too quickly. But object redrawing is still done at 50Hz and is effectively a 50Hz game.

But I guess ProjectX is separating the player sprite & shots from other sprites so object redrawing can be 25Hz in most cases?

I didn't really look into this (or if I did, it was way too long ago).

[dml]

So I got a bit carried away with this one. It was meant to be an example but it got complicated fast.

https://www.youtube.com/watch?v=D1oAdc6MjQM

I should stop mucking about with these and focus on my list of stuff to do!

[TheNameOfTheGame]

Wow, impressive! The STE is one hell of a machine with your engine!

[dma]

Ahahah, that latest R-Type game example is crazily smooth, amazing.
Maybe STe R-Type Deluxe could be rebased on this engine? :O

[dhedberg]

So I got a bit carried away with this one. It was meant to be an example but it got complicated fast.

https://www.youtube.com/watch?v=D1oAdc6MjQM

I should stop mucking about with these and focus on my list of stuff to do!

That's one heck of an example!
Made my day! Shows what this machine is capable of in the right hands!

[marss]

Wow

[EvilFranky]

Amazing to see stuff like this Doug!

Am I correct in thinking the sound is just a sample playing over the top? Sound effects don't appear to tie in with the shots in the gameplay

[dml]

Am I correct in thinking the sound is just a sample playing over the top? Sound effects don't appear to tie in with the shots in the gameplay

Yes I just stuck that over the top for the arcade feel I had started preparing to add audio to this but realistically I just don't have time to work any more on it right now so I cut it short and it is what it is. I'll return to the audio in a little while.

[masteries]

So I got a bit carried away with this one. It was meant to be an example but it got complicated fast.

https://www.youtube.com/watch?v=D1oAdc6MjQM

I should stop mucking about with these and focus on my list of stuff to do!

More than wonderful! STE is an arcade machine!

You have the source code for walkpath at your inbox; I am working hard on the Run & Gun, but you are working more hard on the R-Type arcade conversion xD

[dml]

More than wonderful! STE is an arcade machine!

You have the source code for walkpath at your inbox; I am working hard on the Run & Gun, but you are working more hard on the R-Type arcade conversion xD

Yes I just noticed it, thanks - I should be able to add this type of walkpath extraction to agtcut.

As for the R-Type samples - I will tidy them up and allow them to share some of the code (levels 1,3 have some custom things but a lot is really the same). When ready, I'll put the source into the repo.

And I can't wait to look at the latest Run & Gun progress!

[DarkLord]

Gawd, if we could have had this leading up to the STe's release!

[mrbombermillzy]

Gawd, if we could have had this leading up to the STe's release!

Yeah, and the STe has the Nickel! lol I love it Doug...Top form as always.

Im intrigued as to the inner workings of this new custom virtual IC.

Does it manage the MFP and interrupts or is there something more esoteric at play here?

[dml]

Yeah, and the STe has the Nickel! lol I love it Doug...Top form as always.

Im intrigued as to the inner workings of this new custom virtual IC.
Does it manage the MFP and interrupts or is there something more esoteric at play here?

Yes it just goes through a displaylist-like table of instructions set up on the game side, and uses it to generate some 68k interrupt code into a ringbuffer, all strung together. So using it is a bit like working with copperlists, defined in C. A bit higher level though - the instructions are things like selecting a new viewport or changing some colours. But you can poke HW regs with it too, like Copper.

It's more expensive than Copper HW of course, but it works well if used carefully. And it's easy to set up and refresh between frames.

The R-Type level #1 demo actually changes the viewport config via Nickel on the frame just before the fade-in, to enable the parallax view - and each fade step is a new Nickel program (well the existing one, edited and re-sent).

[Playmobil]

I am captivated by your work dml, it's impressive!

[dml]

I am captivated by your work dml, it's impressive!

Thanks! Also to everyone who commented recently but I didn't reply to every one!

There are some more ideas on the way, as soon I can find the time to try them out.