Quake 2 on Falcon030

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team

DrTypo
Atari freak
Atari freak
Posts: 73
Joined: Sat Apr 09, 2011 12:57 pm
Location: Paris, France

Re: Quake 2 on Falcon030

Postby DrTypo » Sun May 17, 2015 8:57 pm

Thank you Doug for the nice comments!

I put together a small test map using GTKRadiant and a few materials from UE4.
I am more of a coder than an artist, so I think an actual artist who likes challenge could produce very good results for the Falcon.

It seems the forum ate my previous post.
I'll put link to screenshots of my map instead of attachments:
A look at the sky
Inside a room
Transparency

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Quake 2 on Falcon030

Postby calimero » Sun May 17, 2015 9:38 pm

@DrTypo these screenshots looks great! :)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Mon May 18, 2015 7:25 am

hencox wrote:...I've been fiddling around with making my own isometric 3D game by generating static bitmaps in four directions of the 3D objects I've created in Blender, but if I could use your engine instead it would be so cool. :mrgreen:
A few questions (sorry if they were already answered somewhere on the other 30 pages):


I think it would depend on which bits could add value for your design. If just the rasterizer is used, it could be enough - but the texture mapping system assumes 3D vertices with z/depth. Isometric drawing would probably need a fiddle to flatten the perspective (I kind of had to do that for the skybox but a more generic isometric viewport would be more comfortable). Also the main drawing overhead on F030 is perspective correction for texture pixels and that isn't needed for isometric projection - so that probably could be dropped and made faster :-) However currently the rasterizer it's not ideal for isometric drawing and would need some changes. At best a very narrow field of view might work meantime.

hencox wrote:1) Does your engine require feeding it WAD-files for all the graphics data or can I do it in my own special way?


The current demo/viewer is certainly set up to load and display .BSP models as the primary scenery. However the engine layers are separated out so you can feed your own geometry at it. The .BSP loader isn't fundamental to operation (some tidyup is still needed here though).

The skybox for example is a model which gets manufactured in memory using some similar structures to the .BSP model (but without the BSP tree and other Quake-only stuff) and is then used as an independent model with its own view transform. Some helper functions are used to finalize the model (format the vertices into fixedpoint etc) before it can be drawn.

There is still some FPU involved in model loading/setup but this is gradually disappearing. There is also some in the camera code, also to be removed. There is none in the drawing code itself.

I'm also starting work on alternative model loaders for common formats.

hencox wrote:2) Does the engine support a total of two texture layers, or perhaps a layer with a constant colour and a texture layer on top of that? I'm currently using a base colour and on top of that a semi-transparent texture layer generated by Blender to give the illusion of ambient occlusion.


It uses two source textures - a shareable base texture and a unique lightmap texture, precombining them JIT into a surface cache. The pixels are rendered from the surface cache in one pass (important for speed on F030). However there are some variations on this possible, including lightmap-only, or lightmap+single colour approximation, or just basetex (for light emitting surfaces) and so on...

The real limiting factor is the compute work for perspective correction for texture addressing. This doesn't leave much time to do anything else per pixel on the DSP, without slowing down the render. So most shading tricks must be done via the surface cache or the CPU+tables.

The perspective correction isn't fundamental to drawing either - it's possible to have a DSP-side routine corresponding to the CPU-side drawing mode which does some other shading function e.g. affine mapping plus some other operation.

Some of this is a bit hardcoded at the moment but trying to make it easier to overload useful bits...

hencox wrote:Looks really nice for rocks etc, so my conclusion is that the ambient occlusion texture layer is more important than the base texture.


I agree 100% - have long considered base/detail textures subordinate to geometry and lighting. It's one of the things the 4th video tries to illustrate - it uses a single texture only, shared between two worlds. In fact even that texture is quite heavy for what was intended but it was necessary to hide some lightmap block artifacts and shading subtlety is limited in 16bit colour also.

[EDIT] "base/detail textures subordinate to geometry and lighting" - I could have qualified that a bit better. I mean in the context of making convincing looking scenes with as little data as possible. There are many situations where the opposite is still true.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Tue May 19, 2015 10:07 am

I had some thoughts recently which should improve the engine performance on base machine.

I'm also getting good feedback on what needs fixed to make it 'usable' for something. It's still quite raw and cumbersome to make and test data. I suppose any serious effort to make content for it would be slowed down by those things.


Anyway, a few ideas:

- the surface cache logic can be modified to split duty between 'parallel' (free) updates and immediate updates, making it possible to eliminate flatshading on surfaces not seen before. this slows things down briefly, but coupled with some other changes below - not necesssarily!

- the flatshading doesn't involve any lighting, but this is not a rigid limitation. its probably possible to texture directly from the lightmaps, bypassing the surface cache, while still modulating by the average texture RGB (single flat colour). This means you at least get the lighting detail on surfaces which aren't ready yet, even if you don't get the base detail as well.

- the surface cache algorithm itself is wrong, being targeted for a machine with really fast memory - able to update all the active surfaces within a frame or two unhindered. not so on Falcon. but changing the algorithm changes the metrics. one obvious change is to avoid a single big circular rover (which has a bad, and easily encountered worst case - wiping out useful surfaces frequently if you walk in a circle) and use a separate one for each detail level. This has two useful effects. One is to prevent distant surfaces purging nearby ones (made worse by impact of perspective, creating many small distant surfaces competing for a few nearby ones). Another is to improve the probability that each surface has at least one miplevel not yet purged, which can act as approximate stand-in for the missing miplevel until it becomes available (using heuristics to decide between ideal mip, available mips, lightmap only, flatshade fallback). Ultimately, avoiding a circular rover is actually better, but costs more CPU at drawtime. I might attempt this later.

- i made a discovery a few weeks back while debugging the skybox which might allow a faster implementation of the texturemapping and span renderer. i wont get to try this for a bit, but its a worthy investigation.

- the loader has already been improved to remove memory fragmentation, so more stuff can typically be loaded in the same footprint. however the textures still compete for space with renderable surfaces. the textures need to have their own cache so they may be kicked and reloaded on demand, as is the case for BadMooD.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Tue May 19, 2015 6:31 pm

One extra thing I forgot to mention. Since the textures were enabled, the engine is running with 32bit vertex fields. This was necessary to stop *really* bad problems with texture sparkles, since the vertices move in some direction or other when you chop precision bits off the position. This is enough to cause the texturemapping to start looking off the edge of the texture at seams all over the map.

The flat-shading demos used 16bit vertices, since the precision loss isn't noticeable. 32bit vertices cost more to transfer than 16bit.

However if a map is processed such that textures don't stop exactly at polygon seams, the problem goes away. It's not really possible to do this by hand because of the BSP chopping things up later and making seams in places you can't predict - but there might be some combination of mapmaking and processing that buries the problem, and would allow the engine to run a bit faster with 16bit vertices.

hencox
Atarian
Atarian
Posts: 9
Joined: Thu Jul 18, 2013 4:34 pm
Location: Göteborg, Sweden
Contact:

Re: Quake 2 on Falcon030

Postby hencox » Tue May 19, 2015 8:20 pm

dml wrote:
hencox wrote:...I've been fiddling around with making my own isometric 3D game by generating static bitmaps in four directions of the 3D objects I've created in Blender, but if I could use your engine instead it would be so cool. :mrgreen:
A few questions (sorry if they were already answered somewhere on the other 30 pages):


I think it would depend on which bits could add value for your design. If just the rasterizer is used, it could be enough - but the texture mapping system assumes 3D vertices with z/depth. Isometric drawing would probably need a fiddle to flatten the perspective (I kind of had to do that for the skybox but a more generic isometric viewport would be more comfortable). Also the main drawing overhead on F030 is perspective correction for texture pixels and that isn't needed for isometric projection - so that probably could be dropped and made faster :-) However currently the rasterizer it's not ideal for isometric drawing and would need some changes. At best a very narrow field of view might work meantime.


I was thinking of skipping the isometric perspective if I'm going to try real 3D with your engine. But if you want to have a go at making an isometric version that could be even faster, I won't complain :D

If you think the engine might be ready for someone else to try out, just give a hint. :-)

/Henrik

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Tue May 19, 2015 8:52 pm

Hi!

hencox wrote:If you think the engine might be ready for someone else to try out, just give a hint. :-)
/Henrik


The main problem I think is removing the last FPU code (really, C code with floats) from the camera setup and other related bits. It's not such a big job in fact - just haven't quite got there yet.

I don't think the collision detection code matters so much as it really only applies to Quake-like maps so it can be left alone for a while.

So it's quite close I think to being hackable for some alternate purpose or other. Not quite there yet - but close! I'll keep you updated :D

DrTypo
Atari freak
Atari freak
Posts: 73
Joined: Sat Apr 09, 2011 12:57 pm
Location: Paris, France

Re: Quake 2 on Falcon030

Postby DrTypo » Wed May 20, 2015 10:48 am

I made another demo map.
This map uses a custom palette, not the default Q2 palette.
The textures are UE4 package "modular Sci-Fi Hallways".

Screenshots:
Room
Corridor
Room with a scene

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Wed May 20, 2015 10:59 am

That looks really great :-)

Did you model the rooms by hand in GTK? Looks like a lot of work there.


I will spend a little time checking my q2map changes against existing maps, to make sure the basic functionality is still ok (and fix, if not). I think it can still be helpful for interiors because I added stuff to improve light sampling.

You can also increase the number of bounces (I used 32 bounces in the last video, although the benefit falls off sharply after the first few), and set the ambient light colour separately, which might be more useful indoor, where the skybox can't reach, and point lights or emitters perhaps aren't abundant enough. It's better not to use ambient and rely on bounces, but sometimes it can be useful too.

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Quake 2 on Falcon030

Postby calimero » Wed May 20, 2015 11:03 am

DrTypo, this looks amazing! I never thought that falcon could display such grafix. Can you made video?

DrTypo
Atari freak
Atari freak
Posts: 73
Joined: Sat Apr 09, 2011 12:57 pm
Location: Paris, France

Re: Quake 2 on Falcon030

Postby DrTypo » Wed May 20, 2015 11:43 am

Thank you for your appreciation!

@Doug: Yes, the map is modeled by hand with GtkRadiant. I think the texture makes it look more complex than it really is.
I'm curious about your modified q2map!

@Calimero: I'll try to make a video. My last try with Hatari produced a choppy result...

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Wed May 20, 2015 12:48 pm

Hi!

Well for some reason this map runs blistering fast in my (latest) Hatari. It's not a completely honest test because unlike the older (1.7) Hatari, this one is a bit faster than a real Falcon. The real HW performance is somewhere in the middle, between old and new Hataris.

Still, this is showing 12-14fps all the time, which is much higher than the other maps I tested. The main room with Q symbol shows 13fps! I'd usually see around 9-10fps in Hatari.

So you somehow made an optimal Falcon map it seems :D


(I probably have some optimized settings in my build again, whereas you have everything turned on maximum for 'art production' work (heh!) - but still this is quite a bit faster than any of my other maps)

Hatari runs constantly with FrameSkip=5 these days even on my decent desktop PC. So it's not keeping up with the emulated machine when running this engine. Not sure when that began - I wasn't really paying attention - but its a definite source of choppyness here at times. It goes extra bad if power-saving kicks in...

[EDIT]

Testing on a real Falcon, the same map shows anywhere from about 8fps to 12fps, and stays in the 9-10 region most of the time. Its sitting now at 11fps in the middle of the main room with the 'Q'

If you hit the '0' zero key, it should turn on the FPS counter.

Also worth monitoring the FS: frameskip value in Hatari's status panel - assuming its configured to AUTO in the main settings dialog. If you set it explicitly to 0, it may feel choppy without any visible cause...

[EDIT 2]

The figures for the real Falcon were taken from VGA. Not tried RGB.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Wed May 20, 2015 6:27 pm

@DrTypo - I had to fix a bug in q2map - it was crashing because the TGA files which come with your map are 8-bit palette type and it was expecting 24/32bit images. This is fixed now so it seems happy.

It does seem to light the room properly judging by the shading but this map uses a custom palette, I can't tell for sure in Q2 itself. Need to try it on the Falcon....


...well it looks ok. It's brighter than the original version - not sure if that's the extra bounces or q2map's light calibration. But there are shadows without any hard black areas.

I am not sure what the other Rad tool was doing with those .WAL textures (or if it was in fact using the TGAs) but I suspect it may not have the right emission values for each texture if it's loading the .WALs. I made sure q2map prefers TGA/PNG/JPG over .WAL for lighting.

I'll look closer at the light level difference when I get more time...
You do not have the required permissions to view the files attached to this post.

DrTypo
Atari freak
Atari freak
Posts: 73
Joined: Sat Apr 09, 2011 12:57 pm
Location: Paris, France

Re: Quake 2 on Falcon030

Postby DrTypo » Wed May 20, 2015 7:40 pm

@dml: well that was a strange bug. The tool I'm using, quemap, never complained. I don't know if it is using the .wal or .tga files. I have to check and remove the .tga files...

The extra luminosity might indeed come from the multiple light bounces.
Did you add new command line flags to configure the renderer or are the settings hard-coded?


@calimero: I made a quick video of the map: https://youtu.be/SE3VnRU6p4s

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Wed May 20, 2015 7:43 pm

Here is my modified version of q2map.exe

https://dl.dropboxusercontent.com/u/129 ... ap_dml.zip

It contains the BSP, VIS, RAD steps in one package, as does the original q2map (see q2map docs for the standard commandline options). However the RAD step has been changed by me. See the .txt for details on the main changes.

There is a prefab skybox.map file included which defines the special skybox used to prelight the scenes in the last video. It transfers both sunlight and 'cloud light' into the scene, with the sun position & colour info set within the actual map's worldspawn entity (i.e. you need to add the skybox *and* the sun entity fields to your map to use sunlight).

There is also a file providing sample commandlines for the 3 steps involved (BSP,VIS,RAD)

The sunlight upgrade was meant for open maps suspended within a giant skybox - but it should work through windows from normal rooms, with some care over wasted volumes between the skybox and the actual room walls.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Wed May 20, 2015 7:51 pm

DrTypo wrote:@dml: well that was a strange bug. The tool I'm using, quemap, never complained. I don't know if it is using the .wal or .tga files. I have to check and remove the .tga files...


The bug I mentioned was only in my tool - won't affect the other ones.

However I mention the .WAL issue because the .WAL format assumes a palette, and the RAD tool will assume the Q2 palette by default, since its not stored in the WALs. therefore - wrong reflectivity/emission info when using .WAL files created with a custom palette! This might account partly for differences in light level...

Generally soft lighting is a good sign - if walls are lightly coloured (or white) and there is any light in the room, it should reach everywhere. If there are black areas, the radiosity is not transporting light far enough, or with enough bounces. Assuming that side of things looks ok, its then a case of adjusting light levels locally then everything globally if necessary... ambient hacks last of all, if at all :)

Of course reducing bounces can be useful but too few and it can look like a bunch of point lights in a dark room. The images posted here are neither of those extremes, but differ visibly probably because of the bounce count.


DrTypo wrote:Did you add new command line flags to configure the renderer or are the settings hard-coded?


On the Falcon side everything is still baked in when compiled - in the q2map tool, its configured via commandline and worldspawn map editor fields (details in most recent post)

I'm looking at the Falcon side still - will need a bit of time to make the important ones configurable.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Wed May 20, 2015 7:55 pm

Video looks good.

BTW one hint with Hatari & video.... best use the BMP codec and make plenty of space available.

Must also reconfigure frame-skip to 0 (avoid auto!), otherwise the recorded video can suffer judder and strangely missing frames. I had to learn the hard way here :D

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1960
Joined: Sun Jul 31, 2011 1:11 pm

Re: Quake 2 on Falcon030

Postby Eero Tamminen » Wed May 20, 2015 10:46 pm

dml wrote:BTW one hint with Hatari & video.... best use the BMP codec and make plenty of space available.


Did you try using lower PNG levels as explained here:
http://hg.tuxfamily.org/mercurialroot/h ... ording.txt
?

User avatar
Mindthreat
Captain Atari
Captain Atari
Posts: 204
Joined: Tue Dec 16, 2014 4:39 am
Contact:

Re: Quake 2 on Falcon030

Postby Mindthreat » Wed May 20, 2015 11:00 pm

Looking incredible! Those screenshots give me a spaceship/corridor type game feeling, which is awesome!
"My attempt at trying to create cool things for the Atari Jaguar:" - http://www.RISCGames.com

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2306
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Quake 2 on Falcon030

Postby calimero » Thu May 21, 2015 3:40 am

DrTypo wrote:@calimero: I made a quick video of the map: https://youtu.be/SE3VnRU6p4s

thanx! it is awesome! this could be some really nice space game :)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Thu May 21, 2015 9:28 am

Eero Tamminen wrote:Did you try using lower PNG levels as explained here:
http://hg.tuxfamily.org/mercurialroot/h ... ording.txt
?


Actually yes that is better, but it's still a bit slower than BMP codec and in the end I had trouble decoding the PNG AVIs with my convertor. However in terms of performance PNG is much better now and doesn't grab nearly so much space....

The main problem I had recently is in relation to frameskipping while recording AVIs. Depending on how you configure the frameskip option, it affects the AVI. When playing back the AVI, it appears to jump and stutter (especially so if the host machine wasn't keeping up during the recording). However it works well if configured with FS=0.

DrTypo
Atari freak
Atari freak
Posts: 73
Joined: Sat Apr 09, 2011 12:57 pm
Location: Paris, France

Re: Quake 2 on Falcon030

Postby DrTypo » Thu May 21, 2015 10:00 am

@eero: Thank you for pointing this documentation. Using ffmpeg helps a lot in making video. I used VLC to convert the video into a usable format and then avidemux to crop the video. ffmpeg can do both in one step.

Thank you guys for your comments. It would be cool to be able to develop a game based on this engine.
Doug will make it possible eventually! ;)

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1960
Joined: Sun Jul 31, 2011 1:11 pm

Re: Quake 2 on Falcon030

Postby Eero Tamminen » Thu May 21, 2015 7:12 pm

Mindthreat wrote:Looking incredible! Those screenshots give me a spaceship/corridor type game feeling, which is awesome!


I agree, I would just want to view them in their full glory, now they have some fuzzy scaling applied to them...

Markybhoy
Atarian
Atarian
Posts: 1
Joined: Sun May 24, 2015 2:38 pm

Re: Quake 2 on Falcon030

Postby Markybhoy » Sun May 24, 2015 2:52 pm

Hi Doug,

I used to have a Falcon when I was around 13 and used to enjoy your demos, I think I might still have some of them on floppy somewhere.
I also had a lot of fun with Apex back in the day.

I've probably bumped into you in the past down the Barras :)

It's great to see your are still doing cool stuff on the machine.

I tried to learn C/asm at 13 but didn't get very far, wish I had sticked with it!

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Quake 2 on Falcon030

Postby dml » Sun May 24, 2015 6:25 pm

Hi!

Markybhoy wrote:I've probably bumped into you in the past down the Barras :)


That's possible - I went there a few times to talk 68k with Neil, but he, Frank and a few of the others made it a regular Atari destination :-)

Markybhoy wrote:It's great to see your are still doing cool stuff on the machine.


Thanks!

Markybhoy wrote:I tried to learn C/asm at 13 but didn't get very far, wish I had sticked with it!


I must have started with asm at 14 or 15 and remember it wasn't easy... strange concepts for someone that age. But it was necessary if you wanted to write demos then :)


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 4 guests