dml

I don't know if I ever posted in here about the project, but I have been working on an STE game engine called 'AGT' for a number of years now and have slowly put together a YT playlist showing some of the example projects. (If you also read AtariForum this is probably old news, so this is for the benefit of AA readers mainly) The source for many of these samples are in the engine repository already, some are new and still being finished/cleaned up. The project can be found on bitbucket as a GIT repo and Wiki resource: https://bitbucket.org/d_m_l/agtools/src/master/ The engine is coded in 68k of course and uses the Blitter & other STE hardware features. AGT is really aimed at programmers with a bit of C experience who are interested in working on Atari games but don't want to spend weeks or months developing optimised 68k routines to do the most common tasks on STE hardware. It can't necessarily support every kind of game equally well (certainly not 3D games!) - but it does capture most of the things you'd need to implement a 2D scrolling shooter, platformer, puzzle game or maybe even a tilemap-oriented RPG. The game dev side is intended to be C or C++ based. All the samples are coded in C (or 'light C++' for some engine features). Objects on the screen are abstracted through entity objects & viewports which can be given behaviour and interaction rules & responses. With these building blocks you can code up most aspects of your game idea fairly quickly. While writing games is never easy, this does let you get ideas off the ground quickly. It also leaves enough room for you to code things outwith the engine mechanisms where necessary, if handled with care. There are some custom tools provided to convert art assets to use in the engine - different kinds of sprites, backgrounds and palettes. The toolchain uses Vincent's GCC 4.6.4 compiler (although it has integration for BrownELF GCC 6.2 & 7.1 as well) and ggn's RMAC assembler for 68k for the internal stuff. AGT development has generally required Cygwin running under Windows but has recently been updated to work under Linux (using WINE for some of the tools), WSL/Ubuntu Linux and to a lesser extent MacOS (which needs a native version of some of the tools to run under Catalina, which doesn't allow 32bit or WINE stuff to run now). This project is an ongoing work-in-progress and sometimes has rough edges. The Wiki is always behind the engine by a couple of steps. The samples aren't all super tidy or consistent. However I do maintain & support it, fixing bugs, adding features etc. If you're thinking of kicking off a game on Atari STE, this might be worth a look ?

Hi! Actually it's not a change in direction. It's a continuation of what I was doing, where I left off. (See the notes in the video)

I suppose it depends on what you're trying to do. This was an exercise in rendering fractals, and is an efficient (and optimised) method for it. Triangles would have been a poor choice for this kind of object on any kind of hardware. If you were rendering (e.g. hand-modelled) polygonal objects however, then a triangle based surface renderer would be fine.

Ok the program is in bad shape where i left it, but a couple of screenies are sitting in my Hatari dir. Rendered on 16MHz Falcon030 with '882.

I used POVRay a lot on the Ataris, and the Cad3D programs (mainly Sculpt, Control,.Paint) but not the later stuff. I looked at them but didn't use them. I was working on a physically based renderer some years ago, but its probably too slow for Atari systems. I also did some mandelbox rendering with Falcon FPU quite recently. It's raytrace-speed (zzzZZZ), but its a calculation-heavy problem and the '882 FPU is more precision than speed. I can link a build if I can find it - although its basically a very slow screensaver! No controls.

For some reason my AtariAge posts ended up filed in spam. I've been working on a 2D, 50hz game prototyping engine for Atari STE. I recently posted the source & tutorials on BitBucket, with a thread on AF for updates. (Haven't done much with 3D in recent months but getting the itch for that again...)

Really quite incredible to see so many of these running. Especially given the differences in disk, user input and audio - and the different random ways coders went about doing things on ST... and what about all the MFP states those games must be messing with? Impressed!

Half-Life map support added:

For those who missed it... John Carmack knows what a Falcon030 is, had used one (for JagDoom dev), and gave the tiny Falcon scene a thumbs up! https://twitter.com/ID_AA_Carmack/status/598924600945332224 (I don't think it means he used one for the whole project, but still - that made my day!)

Cheers!!! One more - a bit different this time:

A quick bump for any Falcon030 fans - just to say 3 more progress updates have been posted since:

Probably not that useful since it's Falcon-only, but Apex can read/paste 16 colour SEQ from ST and read/write 256-colour FLC animations (Animator Pro from PC). I just mention this because the topic doesn't come up all that often - there are not many Atari programs that can work with those formats and it's pretty close to Cypaint in operation. I also used Cypaint quite a lot in the 90s before writing Apex - so it's not a coincidence

On Falcon the full pixel format is 5:6:5 or %RRRRRGGG:GGGBBBBB with << shifts of 11, 5, 0 respectively. But as CyranoJ indicates, the low green bit is often cleared e.g. %RRRRRGGG:GG0BBBBB because its inconvenient for realtime stuff, and can make images look muddy. In this case you can use consistent 5-bits per terms for RGB, with << shifts of 11, 6, 0 respectively.

Anima's serial disk is very nice. It is definitely worth a look. It's written by somebody who actively develops great code for Falcon so it's going to 'feel right' for that sort of work. PARCP however is also wonderful, and is actually faster because it uses the parallel port. It is undergoing some software changes which will probably make it *ideal* for software development. This is still in beta so I should say nomore - but it's going to make my life easier I would actually recommend getting your hands on both and play around. The cost is tiny and the benefits multiple, if you have any plans to be writing code! You may find one is better at something than the other. There are some other options available e.g. USB floppy emulation, CFlash swapping, possibly CosmosEx in future - but for now the two items above are the business for this task.

Another development progress video showing the latest engine improvements (playlist is organized newest -> oldest):