Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

88 Excellent

About dml

  • Rank
    Space Invader

Profile Information

  • Gender

Recent Profile Visitors

5,382 profile views
  1. 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)
  2. 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.
  3. 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.
  4. 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.
  5. 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...)
  6. 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!
  7. 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!)
  8. Cheers!!! One more - a bit different this time:
  9. A quick bump for any Falcon030 fans - just to say 3 more progress updates have been posted since:
  10. 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
  11. 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.
  12. 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.
  13. Another development progress video showing the latest engine improvements (playlist is organized newest -> oldest):
  14. 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.
  • Create New...