Bad Mood : Falcon030 'Doom'

All 680x0 related coding posts in this section please.

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

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Feb 02, 2014 11:51 pm

Zamuel_a wrote:I think Duke used portal / sectors and not BSP trees, or a combination of them. Portal / sectors is the best way to speed up an FPS engine I think, since it's very easy to just draw what you see.


It definitely used portals for the mirror effects. I'm not sure about the map though - I thought it was derived from the Doom engine with similar constraints. Portals don't have the same kind of constraints (Descent used a portalized map). But I suppose it could be totally different - haven't looked at it in years :-)

I had a pet project on the ST long ago - a portal engine named LookingGlass - but didn't get much beyond a few rooms (no map editor - typed in room definitions!).

Did a much better portal map editor many years later for the first Carmageddon II project (before it got canned), as a Maya plugin, using CSG to find the portals.

[EDIT]

Yes you're right - looks like a classic portal/adjacency system - no BSPs involved.

So it would need done from scratch, but efficient for rendering yes.

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Bad Mood : Falcon030 'Doom'

Postby Zamuel_a » Mon Feb 03, 2014 2:21 pm

I think the source code for Duke 3D is available for free. Maybe the texture routines could be reused from DOOM? Or atleast parts of it.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Feb 03, 2014 2:45 pm

Zamuel_a wrote:I think the source code for Duke 3D is available for free. Maybe the texture routines could be reused from DOOM? Or atleast parts of it.


If the surfaces use the same rules e.g. tiling only for textures @ 128 high, no wall textures taller than 128 high etc, then the texturing could be used without modification. Otherwise it would need some changes.

The texturing stuff depends on custom textures, conversion, resource management, so that would need to be moved across too and special cases handled for that.

Floor/ceilings/sector oriented stuff - hard to say how much overlap there could be without more familiarity with the engine.

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Bad Mood : Falcon030 'Doom'

Postby Zamuel_a » Mon Feb 03, 2014 4:51 pm

well if you get bored after you finished DOOM, then you know what to start with :wink:
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby bullis1 » Mon Feb 03, 2014 9:36 pm

The 3D engine that powers Duke 3D is called Build and actually has many more differences to the Doom engine than one may think. It has slanted floors/ceilings, freely scalable textures and sprites, room-over-room architecture, rotating and transforming sectors, moving/travelling structures, coloured lighting, translucency, voxels (not seen in Duke 3D but part of the Build engine), decals, and a bunch more.

I do think that it would be possible to get the Build engine running on Falcon but not Duke 3D. Duke (and some other Build games) uses a runtime-compiled scripting language for game behaviour and AI which adds way too much overhead to make a Falcon port feasible. Like I said though the engine itself is highly efficient and portable.
Member of the Atari Legend team

mikro
Hardware Guru
Hardware Guru
Posts: 2042
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby mikro » Tue Feb 04, 2014 9:55 am

bullis1 wrote:Like I said though the engine itself is highly efficient and portable.

... and it's unreadable and non-portable mess. Makes me puke everytime I look at the code.

User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby bullis1 » Tue Feb 04, 2014 11:55 pm

mikro wrote:... and it's unreadable and non-portable mess. Makes me puke everytime I look at the code.

Really? Are you referring to the Build engine code or the Duke Nukem 3D game code? They were coded by different people. I happen to like Ken Silverman's coding but it seems it's a matter of taste. Also, I've never looked at the SDL releases or anything, just the original DOS code available @ http://advsys.net/ken . I've only briefly dealt with the C source code for Duke 3D and it was to make simple changes.

Anyway, I'm just pleased with the amazing Badmood engine on Falcon :D
Member of the Atari Legend team

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 05, 2014 10:28 pm

Zamuel_a wrote:well if you get bored after you finished DOOM, then you know what to start with :wink:


Boredom doesn't seem likely :) I still have other things to finish - and Duke would be another massive job no doubt.

I'd prefer to start something new, but won't have time to think about that until I'm done with this and the rest.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 05, 2014 10:53 pm

I've had a lot of trouble making sprites work properly in BMEngine, with 3 revisions to the code already and it was still not right. It's fairly close but glitches are common.

I simply can't use the Doom method because it relies on storing lots of edge information until the end of the scene and that breaks my DSP spanbuffer system, largely defeating the point of it.

The main problem is those floors which change texture or light level without also changing height - used for pools of light in doorways, under light panels etc. This causes sprites to be clipped against a false edge - because the sprite's center may be on the far side of the line, and linked to a different sector which doesn't get visited by the BSP until later. By that time the edge is already committed and nothing can be drawn closer than that edge. The scene is strictly depth/occlusion ordered.

There's no obvious problem for steps/windows etc. and it's not a problem at all for normal walls. Fake floor edges cause most of the headaches and can cause large pieces of sprite to go missing at some angles.


I think I now have a solution that works, but it has required a lot of (still incomplete) changes to the source. Not just sprites but other stuff - preparation of sectors, lightlevels etc. and when things get done.

I have solved the problem by 'looking across' certain types of line under specific circumstances, and activating sprites in sectors across those lines ahead of scene order - but this also requires the sector state to be updated at the same time because activating sprites commits their billboard 'lines' and sector light levels to the DSP segment buffer - and those sectors are not yet ready for drawing.

So the natural order of some drawing processes had to be split up and cached in a separate prepare step. It's slightly complicated by the fact sectors can be visited multiple times per frame since they are shared by subsectors, which are the primary scene (BSP) drawing primitive.

The type of line which gets this 'look ahead' is specifically the floor attibute edge type - and sprites which are activated need a special test which determines if they are trying to cross the line (sprite is on near side of line, or on far side of line AND distance to line is less than sprite radius). If they are in this state, they are considered part of the near sector and processed for drawing. Any bits left over get cleaned up when the adjacent sector is visited.

I haven't mentioned ceilings - because glitches are rare and hard to demonstrate. Gravity pulls downwards and most of the crap ends up collecting on the floor :) the very few things which are on the ceiling were placed (manually) away from those types of edge.

The penalty for this is some extra work to do for open segments and some sprites being activated and visibility tested before they normally would, and losing out on some occlusion, because some walls from the current sector haven't been processed/added yet. They still get occluded but occasionally later than usual.

The whole thing is mind-meltingly inobvious so hopefully once this is done it doesn't need fixed again! :)

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu Feb 06, 2014 12:40 am

After all of that there's a 0.9% slowdown when comparing the same timedemo before/after the fix. That's not too bad considering the extent of the changes. There are some optimizations still to be done in that area so it will probably get claimed back too.

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 871
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby EvilFranky » Thu Feb 06, 2014 8:23 pm

A little off topic, but I was wondering this the other day. If there had been an 8-bit chunky mode incorporated in the VIDEL, and Bad Mood was written to use it instead of 16-bit colour...would we have seen performance double?

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu Feb 06, 2014 8:50 pm

EvilFranky wrote:A little off topic, but I was wondering this the other day. If there had been an 8-bit chunky mode incorporated in the VIDEL, and Bad Mood was written to use it instead of 16-bit colour...would we have seen performance double?


No, I doubt it. Although some things could be done differently and help a bit.

The display is built per-pixel and it doesn't matter so much if the pixel is 8 or 16 bits, since the bus is 16 bits wide and one bus access per pixel written.

It's a bit more complicated when you start dealing with lighting lookups, datacache etc. But gains would be nowhere near double.


An easier speedup is to drop per-column lighting - but the savings diminish with a smaller window.

Flat shaded mode doesn't run 2x as fast, for example. Of course a much faster flatshaded version could be done that isn't a proxy for a texturemapping system but I don't see any texture mapping optimization beating a flat shaded pixel plotting path.

mikro
Hardware Guru
Hardware Guru
Posts: 2042
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby mikro » Thu Feb 06, 2014 10:12 pm

bullis1 wrote:I happen to like Ken Silverman's coding but it seems it's a matter of taste.

Your taste must be a very specific one ;-) Good description is here: http://fabiensanglard.net/duke3d, this guy couldn't resist and refactored some parts at least :)

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu Feb 06, 2014 10:52 pm

"Features hand optimized x86 assembly with no C fallback."
- sounds like BadMood :-)

"Only three modules makes the entire codebase hard to mentally break down in sub-modules."
- lol. I'm glad i don't write programs like that anymore (Apex)

"The main Translation Units (game.c and engine.c) are so big that they slow down IDE. Sometimes to the point of crashing XCode."
- I have seen XCode crash while trying to open highly verbose makefile logs - but crashing on a big complicated sourcefile is awesome.

Code: Select all

"static char kensmessage[128];
#pragma aux getkensmessagecrc =\
"xor eax, eax",\
"mov ecx, 32",\
"beg: mov edx, dword ptr [ebx+ecx*4-4]",\
"ror edx, cl",\
"adc eax, edx",\
"bswap eax",\
"loop short beg",\
parm [ebx]\
modify exact [eax ebx ecx edx]\"


- yikes!

I scanned through the 8k lines of source. It's not exactly untidy - just a bit insane. He clearly didn't use naming to keep himself straight - he kept all the knowledge in his head. And yes it doesn't look fun to port.

I imagine he was thinking 3 steps ahead of what he was actually doing, aaallll the time ;)

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Bad Mood : Falcon030 'Doom'

Postby Zamuel_a » Fri Feb 07, 2014 8:27 am

Good description is here: http://fabiensanglard.net/duke3d


Interessting reading. Seems like they divided everything into portal / sectors. Even things like furnitures. I once did a portal based engine on PC, but I just divided it into "rooms" so that in each sector there could be any kind of objects and stuff and they got sorted with a deep sorting routine first. Don't know what might be fastest to do. Sorting a few polygons or divide EVERYTHING into it's own sector.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Feb 07, 2014 10:26 pm

Zamuel_a wrote:Interessting reading. Seems like they divided everything into portal / sectors. Even things like furnitures. I once did a portal based engine on PC, but I just divided it into "rooms" so that in each sector there could be any kind of objects and stuff and they got sorted with a deep sorting routine first. Don't know what might be fastest to do. Sorting a few polygons or divide EVERYTHING into it's own sector.


TBH it was only faster to portalize everything if your fillrate was the biggest problem and there were not many surfaces - otherwise significant time is spent traversing multiple levels of the engine for transform/bounds/rejection/clipping stuff. As fillrate goes up, the cost of the portal rises.

On old machines with low memory bandwidth, small caches and manual pixel plotting across surfaces it was worth going crazy with portals to get rid of all overdraw on a small number of surfaces. That situation didn't last very long after the hardware 3D appeared.

So depending on when you did your engine, it might or might not have been the right thing to do - temporarily :)

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Bad Mood : Falcon030 'Doom'

Postby Zamuel_a » Fri Feb 07, 2014 10:57 pm

I started my engine on a 400MHz PC and did all in software, but later on I converted it to OpenGL and runned it with hardware accelerated 3d, so with the help of the Zbuffer each sector could have anything in them and it didn't matter so much. I also made a raytracer that created lightmaps so the final quality was in line with Quake 2 or so, but after that I didn't do so much and today it's hopless to do anything that can match the high end games so I gave up on PC. Much better to focus on a machine like Atari :wink:
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Feb 07, 2014 11:31 pm

Yep keeping up with PC graphics means octree raytracing in shaders these days. Still, that's fun in a different kind of way - but it probably is a waste of time trying to do anything that looks like 'modern games' because they demand so much data and people now expect that look...

It is a bit more interesting to see what might have been possible on old machines when the fight for software 3D was still on :-)

Zamuel_a
Atari God
Atari God
Posts: 1235
Joined: Wed Dec 19, 2007 8:36 pm
Location: Sweden

Re: Bad Mood : Falcon030 'Doom'

Postby Zamuel_a » Sat Feb 08, 2014 6:20 pm

I remember back in the late 90th. "Everyone" made there own 3d engine. There was even a website called "3D engine list" (maybe it still exist) with links to hundreds of different 3d engines people had made. Some were really good to. Now noone get's impressed by the 3d engine itself, they just care about the game.
ST / STFM / STE / Mega STE / Falcon / TT030 / Portfolio / 2600 / 7800 / Jaguar / 600xl / 130xe

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Feb 09, 2014 9:50 am

Zamuel_a wrote:I remember back in the late 90th. "Everyone" made there own 3d engine. There was even a website called "3D engine list" (maybe it still exist) with links to hundreds of different 3d engines people had made. Some were really good to. Now noone get's impressed by the 3d engine itself, they just care about the game.


Yes there was a time when many people were working on new 'philosophies of engine' for 3D projects :) but it has since faded away. Still the effort involved in making technology for games is huge but there is not so much interest in differentiation because the audience is much wider and less aware of the nature of the advances which have been (or are being) made.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Feb 09, 2014 9:55 am

I have decided to sove the palette shifting required for pickups/health, damage in Doom using a blitter halftone/smudge trick which implements saturate & add arithmetic on select colour channels. This will appear as a sort of gradient raster effect near the window border which fades down over a few frames.

If it looks right it can also be applied near the window border where the event is happening (e.g. pickups affect the lower edge, where damage affects the left/right or upper edge - or two edges - depending on direction the damage came from. I think this will look good, will add a bit to the gameplay while avoiding the need to process the whole window.

It's not clear that the blitter can do this faster than the 030 but I'll start with it and change it later if the CPU is faster. I suspect the CPU can do it with fewer bus reads but we'll see.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Feb 09, 2014 1:25 pm

Tried to make a YT video of the palette shifting fx (powerups, health, damage etc) described above, but the encoding was so bad I deleted it immediately. Here are some grabs instead + use imagination :)

fx1.png
fx2.png
fx3.png
You do not have the required permissions to view the files attached to this post.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Feb 09, 2014 2:04 pm

...and the improved version (which is obviously cheaper ;-) ) appears as a raster-like effect near the window edge and fades down quickly over time.

Pickups (blue, green) will appear at the lower window border - maybe both upper and lower for big powerups. Damage will be red and located left/right depending.

fximproved.png
You do not have the required permissions to view the files attached to this post.

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2019
Joined: Sun Jul 31, 2011 1:11 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Eero Tamminen » Sun Feb 09, 2014 5:44 pm

dml wrote:...and the improved version (which is obviously cheaper ;-) ) appears as a raster-like effect near the window edge and fades down quickly over time.

Pickups (blue, green) will appear at the lower window border - maybe both upper and lower for big powerups. Damage will be red and located left/right depending.


What if you would attenuate it a bit differently, with a long fade-off instead of sharper cutoff? Current effect looks a bit like a bar, and I'm thinking that concave looking effect would be "naturally" blended to the player vision.

What about the bio/radiation suit, is that also going to be effect just on borders (for performance reason)?

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Feb 09, 2014 9:01 pm

Eero Tamminen wrote:
dml wrote:...and the improved version (which is obviously cheaper ;-) ) appears as a raster-like effect near the window edge and fades down quickly over time.

Pickups (blue, green) will appear at the lower window border - maybe both upper and lower for big powerups. Damage will be red and located left/right depending.


What if you would attenuate it a bit differently, with a long fade-off instead of sharper cutoff? Current effect looks a bit like a bar, and I'm thinking that concave looking effect would be "naturally" blended to the player vision.

What about the bio/radiation suit, is that also going to be effect just on borders (for performance reason)?


It can be made bigger but it is expensive - it involves two reads and a write for each pixel (hires, anyway) and the blitter version is already quite slow, so this is an attempt at limiting the fill area. The CPU version will be faster in low detail modes at least.

I can make the bar size configurable in the .cfg file but I'll be recommending 8 or 16 pixels on a 16MHz Falcon, especially with multiple bars being drawn at once (damage from left/right or front + pickups).

The falloff is linear, it can be changed to a curve but it will cost more pixels for the same 'visibility level' IMO since a higher ratio of pixels will have higher transparency.

For the bio suit I was going to have it constantly on, upper and lower border. For berzerk, same but red.

Invisibility is already done - but invuln is still needing something done.

[EDIT]

I'll try a square-curve for next time to see if it's still visible enough. If so I'll prefer it over linear.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 4 guests