Bad Mood : Falcon030 'Doom'

[dml]

I think the centroid/contour based effect would be possible only with a new secondary texture map generated for the sprite (just now I'm working with original texture data directly). However this is doable once I extend the cached surfaces to hold secondary texture representations and I think this will be needed anyway to accelerate sprite drawing in other ways. So I can't do it quite yet but a bit later should be possible yes.

(it could make the framebuffer edge errors harder to suppress, will need to think about that a bit more before trying it)

[dml]

Fantastic! Another Falcon bonus, well done Doug

Hoping to get a bunch more in as the more mundane bits (game code, renderer performance problems) start needing less effort.

[Eero Tamminen]

Hoping to get a bunch more in as the more mundane bits (game code, renderer performance problems) start needing less effort.

Does "game code" include sounds?

PS. Doom doesn't anymore work with Hatari oldUAE core, only with WinUAE CPU core.

PPS. I changed the profile post-processor title to "Visits/calls". Hopefully that reminds better of what the numbers really are about.

[Eero Tamminen]

I think the centroid/contour based effect would be possible only with a new secondary texture map generated for the sprite (just now I'm working with original texture data directly).

Why?

I would assume that at least z & x middle position for a sprite are known where this is calculated and middle y-offset can be assume (hardcoded) based on average enemy heights. With what I described, there shouldn't be any need for extra texture data, not even actual pixel contents in the sprite texture, just the non-fully-transparent span extents in the texture and the y-height of the currently processed span within the sprite... I would assume that to be less information than what you use for the current transparency implementation?

[dml]

Does "game code" include sounds?

Sound will be done of course, but I'm not expecting the sort of pain experienced with some of the other bits so far. Hopefully not anyway.

PS. Doom doesn't anymore work with Hatari oldUAE core, only with WinUAE CPU core.

Random guess: some DSP-timing-sensitive changes around wall insertion. I can test this one quickly by enabling pedantic DSP handshaking.

PPS. I changed the profile post-processor title to "Visits/calls". Hopefully that reminds better of what the numbers really are about.

Great! It will assist my poor memory

[dml]

Why?

I would assume that at least z & x middle position for a sprite are known where this is calculated and middle y-offset can be assume (hardcoded) based on average enemy heights. With what I described, there shouldn't be any need for extra texture data, not even actual pixel contents in the sprite texture, just the non-fully-transparent span extents in the texture and the y-height of the currently processed span within the sprite... I would assume that to be less information than what you use for the current transparency implementation?

I'm still not sure I understand your suggestion (particularly since you referred to a sqrt() op and there's no time for that in pixel drawing except by burning textures in advance?) but it seems like it might be something like just using the framebuffer as the source directly, but scaling at a slightly different rate based on sprite distance from viewer? If not, please explain a bit more.


What I *thought* you were suggesting was working out contours from the sprite edge (distance formula or equiv.) and generating an offset map, with which a more predator-like effect could be done. You'd get 'rings' around the shape following the edge but at different depths from the sprite edge.

As I said before, there are lots of ways to do something like this so that's 3 ideas already and we're not done yet - and I might still not be understanding your own point

[dml]

In fact there's no reason to be stuck with one shader for any given thing, we can have a variety of them and pick the best ones or just allocate some at random or to specific maps etc.

[Eero Tamminen]

I'm still not sure I understand your suggestion (particularly since you referred to a sqrt() op and there's no time for that in pixel drawing except by burning textures in advance?)

I mentioned sqrt because that's normally used for calculating distance. With squarish image in square texture, the effect from dx+dy would be larger in corners. If one knows how large the values will be for enemies, one can just clamp the value to approximate value of what it would be at middle of the edges instead of resorting to sqrt. (this might not be the best way if some enemies are very thin or thick)

but it seems like it might be something like just using the framebuffer as the source directly, but scaling at a slightly different rate based on sprite distance from viewer? If not, please explain a bit more.

What I *thought* you were suggesting was working out contours from the sprite edge (distance formula or equiv.) and generating an offset map, with which a more predator-like effect could be done. You'd get 'rings' around the shape following the edge but at different depths from the sprite edge.

I would say "rings" are inside the shape, with the effect being largest at the edge.

Hm. Now that you mention rings, it might not look as good as your current method, because it wouldn't show the internal shape of the enemy one gets from using the sprite colors for offsets. It would be more like a "lense" which is shaped according to enemy outline.

As I said before, there are lots of ways to do something like this so that's 3 ideas already and we're not done yet - and I might still not be understanding your own point

Heh, I don't think getting drafty ideas like this correctly across is so important. If thinking about them gives you new ideas, it's nice regardless of whether we understood each other.

[Eero Tamminen]

In fact there's no reason to be stuck with one shader for any given thing, we can have a variety of them and pick the best ones or just allocate some at random or to specific maps etc.

One more potential "shader" type for this could be something that shows just few spots of the enemy and those spots would move around a bit.

For example only colors going over certain threshold could be shown, and this threshold could fluctuate (fairly rapidly with time, e.g. change a bit every frame). If sprite shape is suitably indicated by its colors so that parts in front of the enemy have lighter colors, hopefully this would give the impression of a creature trying to come through from some other (hellish) dimension...

Threshold limit (range) would need to be carefully selected, so that it wouldn't show too much or little of the creature. Limit might need to be per texture & color channel, calculated when generating mipmap... I.e. probably too much work.

[bullis1]

The new invisibility effect is really nice. I'd love to see it in person and in motion some day.

I find this project so exciting even though I can't count a Falcon among my computers. Too bad the TT is never home to any new games or demos.

[dml]

The new invisibility effect is really nice. I'd love to see it in person and in motion some day.

I find this project so exciting even though I can't count a Falcon among my computers. Too bad the TT is never home to any new games or demos.

...actually, Eero has been playing with trying to get an old Q1 port running on TT I shared the code with him and promised to help fix some of my old stuff for that but I've been too busy with random things in BM still.

It won't be fast enough on TT in it's current form but I think some things might be changed to improve that.

Too many things to do!

[EvilFranky]

Q1 on purely 030???!

You lot are crazy lol

Sent from my Nexus 4 using Tapatalk 2

[dml]

Q1 on purely 030???!

Maybe not in its original form (and the AI/game/skeletal animation might be even more of a killer) but the scenery drawing at least could be adapted for TT and you can probably do some decent tricks with fast memory and laying off the FPU which Q1 uses an awful lot for drawing. BM does all of its projection and mapping with integers only and used to do a lot of it on the CPU @ 16MHz... it's a matter of time/effort and deciding on 'acceptable loss' .

[dml]

I mentioned sqrt because that's normally used for calculating distance. With squarish image in square texture, the effect from dx+dy would be larger in corners. If one knows how large the values will be for enemies, one can just clamp the value to approximate value of what it would be at middle of the edges instead of resorting to sqrt. (this might not be the best way if some enemies are very thin or thick)

Yep it was the distance thing that got me wondering if you wanted the 'rings' effect - I had considered offset maps to do this but didn't put the effort in yet (the shader is easy, but generating the textures involves quite a few steps). It might be possible to do it via DSP *without* a texture offset source but IMO it doesn't seem to save time or complexity because you still need a texture map for the mask and it might as well be the offset texture. DSP might be better at handling clipping problems where offset textures need special handling or framebuffer margins. In any case I think we're both talking about the same sort of thing and it should be ok to do by at least one route

I would say "rings" are inside the shape, with the effect being largest at the edge.

Yes indeed, inside the shape, following the edge in some kind of 'strata'.

Hm. Now that you mention rings, it might not look as good as your current method, because it wouldn't show the internal shape of the enemy one gets from using the sprite colors for offsets. It would be more like a "lense" which is shaped according to enemy outline.

This is true but the effect would still probably look pretty good (and quite different - some enemies would be more or less visible depending on movement and background), and it would be worth having both methods.

Heh, I don't think getting drafty ideas like this correctly across is so important. If thinking about them gives you new ideas, it's nice regardless of whether we understood each other.

100% agree I think we're on the same track anyway just the details vary a bit.

[Cyprian]

Q1 on purely 030???!

Maybe not in its original form (and the AI/game/skeletal animation might be even more of a killer) but the scenery drawing at least could be adapted for TT and you can probably do some decent tricks with fast memory and laying off the FPU which Q1 uses an awful lot for drawing. BM does all of its projection and mapping with integers only and used to do a lot of it on the CPU @ 16MHz... it's a matter of time/effort and deciding on 'acceptable loss' .

my TT is waiting

[dml]

Not much time today but was able to do another shader example.

This is a kind of translucency / alpha blend. Not quite the full deal with per-pixel alpha term, more like 'vertex alpha' but enough to do light shafts, more 'spectre' effects and some other useful things. One image shows use with masking, the other without (its a little faster without, and good enough for shafts of light). This can be assigned to transparent walls at sector boundaries so you can make columns of light from ceiling lights which the player can walk around, or through (etc. etc.).

alpha.png

alp2.png

In principle this shader can darken as well as lighten, or saturate, or shift hue / cause other changes to background colours. Not fully explored that yet but plenty of options.

[EvilFranky]

Looks immense Doug.

It's a shame Atari didn't have the hindsight to have Doom commissioned for the Falcon back at the beginning. Imagine having this version running in a shop in demo mode next to the 386's of the time ha!

Faster, 65k colours, 16-bit sound, additional effects, better lighting...

[dml]

Looks immense Doug.

It's a shame Atari didn't have the hindsight to have Doom commissioned for the Falcon back at the beginning. Imagine having this version running in a shop in demo mode next to the 386's of the time ha!

Faster, 65k colours, 16-bit sound, additional effects, better lighting...

Part of the fun for me now is trying to keep this project '386 era' and use only what the Falcon had inside it at the time For the first version done in the 90's the aim was more fuzzy - like it should run on a base Falcon but with plenty of accelerated machines around, it didn't target an exact spec. It also wasn't clear what the end result should be (game? demo? viewer tool? what game?)

This time I think it is more clearly targeted: Doom 1, 16MHz 68030, 32MHz DSP, 14MB ram

Making it run on 4MB will be hard. Still not sure about that one yet. The executable wants 1mb, the framebuffers want up to 1mb, Doom seems to want 1mb for unknown 'stuff' (maybe just 2D patches, not investigated yet), and there is about 0.5mb of temporary space needed for loading, precalcs etc. Not a lot left for BM graphics cache! A lot of this can be shrunk further or made temporary, but if it ever does fit it will be very tight. OTOH while the PC version of Doom did fit in 4MB, it did use 8 bit colour...

The FPU is not really in the spec - it's not much used except for debug/fps/profiling stuff and offline prelighting. I'm planning to take it out.

[EvilFranky]

Well people become more creative the tighter the constraints I think.

Glad this is actually still fun for you mate, can't believe it's been about 4 months now!!

As a Falcon owner (and I believe this is the same feeling others will have) all I ever wanted to see is what the machine would have been able to do when talented developers really pushed it. The demos over the years have been nothing short of incredible, but it's not the same as seeing an end user product like a really polished/technically great game or application (Apex ).

It's been fantastic to see this and the likes of Beats of Rage released over the last year, very exciting indeed.

[EvilFranky]

Oh and this version also looks a hell of a lot better than the Sega 32X version...

[dml]

I think the 32X version is using the Jaguar level data, or maps derived from the Jaguar ones.

The texture count on the Jag has been severely cut, and the geometry simplified in a few places. The transparent textures are also removed (although these aren't frequently used in most maps). This probably has a lot to do with the visual differences.

[EDIT]

Actually the maps look like a hybrid - there are transparencies visible and there are some textures not used on the Jag. So they have been edited at least. But they do look a lot like the Jag maps...

[EvilFranky]

The 32X version is also only in 8-bit colour.

Is JagDoom 16-bit or 24-bit colour?

I can understand that the Jag version would need cut down due to memory constraints, only 2MB RAM...

[dml]

Here's a rough visual comparison between 32X and F030/BM rendering output.

I couldn't find a decent resolution screenshot from 32X in an area I had 'modded' so this was the best I could do in a hurry You'll probably notice that the 32X one doesn't look much different from BadMood running the Jaguar WAD leveldata - almost identical except brightness levels and subtly reduced shading error on the BM version. The benefits of truecolour are a quite lost there, but they begin to show in the other two frames!

32X version:

cmp32x.png

BadMood running Jaguar data:

cmpf30_jag.png

BadMood running PC data:

cmp_f30_pc.png

Dos PC

pc.PNG

BadMood 'modded' for F030 with TC textures:

cmpf30_tc.png

Note that the aspect ratio is a bit different so the rectangle isn't a 1:1 comparison. I took the grabs at 220x115 res which seemed to be the nearest fit in BM to the 32X screenshot I used. I don't know how this compares with the actual 32X resolution but it seemed sensible to match the res on comparison at least.

I also notice the depth-cue lighting effect isn't showing here on BM, because the curve is set too tight and it flattens out after a few 'metres'. I might adjust that later to stretch out the curve a bit to cover more of the scene.

[EDIT]

Dos PC screenshot added from roughly same spot. Main difference from BM running unmodded PC data is shading quality (see the bandy floor, grainy wall).

[EvilFranky]

The lighting in the final BM screenshot is quite incredible. It has fantastic contrast compared with the other versions.

[bullis1]

The 32X version of Doom does not render any transparent/masked walls, even if they are present in the WAD data.It also does not contain any spectres. Also the screen is not strictly 8-bit colour. The main game window uses and 8bit colourmap, anything overlayed on the game window (menu text, Doom logo, etc.) is drawn with its own 8bit palette, and the status bar is drawn using the Megadrive's 9bit palleted tiles. It's somewhat hard to explain but you can potentially have alot more than 256 colour onscreen.

The screenshot comparison isn't quite accurate imo as no 32X emulator correctly emulates the colour. I'm not sure which chip is responsible (I really have to assume its the video encoder Sega chose, or something in the video circuit between the screenbuffer and output) but the output of the 32X is alot more saturated and a bit more high-contrast than what you see in emulation.

I know this is getting off-topic but I've been working on a game using Doom 32X as a base for about a year now so I couldn't resist chiming in on this particular port.