Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

dml

Members
 View Profile  See their activity

  • Content Count

    48

  • Joined

  • Last visited

Posts posted by dml

  1. Posted

    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 🙂

     

     

     

     

     

     

     

     

     

     

     

     

    • Like 11

  3. Posted

    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.

    • Like 1

  5. Posted

    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.

    • Like 1

  7. Posted

    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!

    • Like 3

  12. Posted

    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 :)

    • Like 1

  13. Posted

    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.

  14. Posted

    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.

  16. Posted

    Yeah, I think this is definitely the route I want to take. So, just to verify, I pass a back buffer and a display buffer to the mode setter, draw to the back, and blit. And the blit will automatically copy the frame from the back to the display. Am I right?

     

    You can blit (or use a memcpy() to do the same job) and it will work, but these are old machines and moving that much memory takes ages - has to be done physically by the CPU or blitter, over the same 16bit bus.

     

    The Ataris are better set up to perform a page flipping / surface flipping which is also a common method on PC in exclusive mode. Your physbase/logbase are your pages - the hardware shows you the contents of physbase and hides logbase. Change those pointers over and you'll see the other buffer. There are several ways to set the pointers - Vsetscreen is one of several XBios display calls available. Writing direct to the display HW registers is another way.

     

    Really logbase is only needed by TOS/VDI if you're using those to draw to the backbuffer. If not, only physbase matters. You can write to the backbuffer yourself without informing TOS. But beware things like printf which go through TOS and will corrupt memory if logbase and VDI are not aware of whats happening.

  17. Posted

     

    Yes! Right before I went to bed last night, my brain lit on a pattern that I think will cover it.

     

    - create a mode integer from bit pattern

    - get a screen size (long) from getscreensize()

    - malloc() a drawing surface

    - malloc() a display surface

    - setscreen mode passing the drawing and display surfaces and mode integer

    - get a VDI handle

    - draw something in a while loop terminating on getchar()

     

    Does that sound about right?

     

    Yes this is approximately what you want, if you want exclusive control over the display / framebuffer on a Falcon. Particularly important that you allocate the right amount of space in advance of changing the displaymode otherwise you'll trash memory. You should make sure the buffers are aligned to at least 4 bytes (on an ST, it would need 256 bytes - I usually prefer it as a rule of thumb). 4 byte alignment probably happens automatically with malloc but easy enough to make sure...

     

    char *palloc = malloc(size+256);

    pframebuf= (char*)(((int)palloc + 255) & ~255);

    ...

    ... do something, then exit

    ...

    free(palloc); // not pframebuf!

     

     

    When creating the modecode from the bitpattern, it's usually sufficient (at least to start with) to just get the old mode and mask off the unwanted bits, combining new ones for resolution and colour depth. This helps keep things happy on both VGA and RGB since those flags remain untouched.

     

    Be aware that RGB and VGA modes can be different sizes (200 lines vs 240 lines) for what amounts to the same 'mode' and that other software (BlowUp, Videlity etc.) can change this as well - making it even more important to ask TOS how much memory needs alloc'd. Better not hardcode it to TOS resolution defaults - otherwise boom!

     

    You'll also need to save the old display info and put it back on exiting, particularly if you're using a real machine :) Painful to have to reboot just to open the compiler editor again :)

     

     

    You'll probably find it infinitely easier (more effort, but be less confused, and learn more) to just write directly to the framebuffer rather than go via the VDI, at least in chunky pixel truecolour mode.

     

    1 word = 1 pixel. bytes per line = screen width * 2. easy! Bitplane modes are much more work to get used to coding for, but in the end its the same as an ST, just more planes...

     

    VDI isn't hard to use at all - but depending on what level you fiddle with display settings it may not understand what changes you've made and results can be wrong or just crash. Same situation if VDI is not initialized properly. Learning curve there... most coders using exclusive access to the screen on a Falcon for performance graphics won't bother with the VDI stuff at all...

     

    Hope that helps.

  18. Posted

    No particular order:

     

    - Devpac Developer

    - Dungeon Master

    - Oids

    - Populous

    - Starglider(s)

    - Frontier

    - Mercenary(1-3)

    - CAD 3D (Sculpt etc.)

    - Cyberpaint, Apex(!)

    - ST Replay

    - Xenon 1,2

    - SimCity

    - STOS

    - Backlash

    - Speedball

    - Stuntcar Racer

    - some trackers (can't remember which ones)

    - lots and lots and lots of demos!

     

    Plenty missing from this list - lots of good games - but my memory needs jogging...

    • Like 1

  19. Posted

    :-)

     

    I have some Apex 3 material still to upload but haven't got around to it due to other things going on. My site is several years stale and quite a lot of stuff now waiting to go up, including that.

     

    Yep, Apex was aimed at pixel painting/editing and especially animated sprites or other moving sequences for game dev (since that's what I was doing a lot of at the time). It has some other, more unusual tools outside of pixel painting (e.g. image processing/recolouring by brush) but for natural painting style on single images there are better alternatives.

  21. Posted · Edited by dml

    Unfortunately I don't think I have an electronic copy, and the printed one is buried somewhere. But I can remember a lot of the controls.

     

    Most common ones:

     

    - right click in main window area to make menus appear/disappear when drawing

    - press 'z' to zoom in a level, or '\' to zoom out (keys next to each other). can do this to zoom while dragging also.

    - I think spacebar scrolls/centers the canvas at the mouse (e.g. while zoomed), but zoom/pan do this automatically as well.

    - left click on an icon activates that tool. IIRC right click accesses settings for the tool

    - you can clone the current image (frame) any number of times using the 'insert frame' buttons at the left and right end of the jog shuttle bar at the bottom

    - with this you can set up animations. there's a slider on the jog shuttle to move between them, and a play button to play back the animation

    - TC or 256 colour mode, and bigger-than-screen-canvas configuration can be set using the config icon somewhere on the lower left

    - cut/copy/paste works mostly as you'd expect, but you can load/save the pastebuffer via a special entry in the load/save page

     

    Importing/exporting single or multi-frame images/animations/brushes is a bit more complicated but it's all accessed through the load/save page. If you've ever seen Cyberpaint on an ST, Apex is very like that program for the Falcon - the Cyberpaint manual might be a clue for some of the key shortcuts too.

     

    If you have a specific question I might remember the answer :)

  23. Posted

    Thanks :)

     

    I've had some feedback now that it works for most people who have tried it, although a couple of odd cases remain (one machine hangs early during startup, another hangs at random points ingame - albeit on a machine which had some ongoing DSP issues). Everyone else has been able to get it to run reliably so that's kind of reassuring.

     

    Updates will be posted soon addressing bugs, graphic glitches and improving things...

  24. Posted · Edited by dml

    Hi,

     

    The beta build is made to work only with Ultimate Doom v1.9 (not Doom2). The error about BMT2.WAD means its trying to run Doom2, and trying to load the BadMooD Doom2 extension data, which does not exist yet.

     

    Have a look in the readmes, or on the main site for more info on setup and the correct WAD files to use. e.g. here:

     

    http://devilsdoorbell.com/setup/

     

     

    Doom2 support will come later - but for now the game is the Doom1 episodes only.

     

    (when you do obtain the right WAD, please delete the BMC folder cache so it can be recreated cleanly with the new WAD - it should do this itself but I don't trust it 100% yet :-)

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...