Bad Mood : Falcon030 'Doom'

[shoggoth]

I guess I should start doing something useful again instead of this shader stuff eh.

It's like see-through underwear. I can see the new demo binary underneath that stuff.

[bullis1]

You do whatever keeps you interested dml. It's all interesting.

[EvilFranky]

Hmmm, it could be used for see through water

Sent from my Nexus 4 using Tapatalk 2

[dml]

...trying to get the wobbly lava/slime/water shader to work again using the DSP this time. Sort of half way there. When I'm done with this will look at weapon overlays in the game.

[dml]

I think I have a slow version of it working now on the DSP, so it just needs animated and optimized. Couldn't quite remember how it worked but it seems to be a transform using the formula below (hiding the fixedpoint detail):

Code: Select all

 u' = u + sin(v * turb_period) * turb_magnitude
 v' = v + sin(u * turb_period) * turb_magnitude

[dml]

Got a new version of the liquid shader now which takes parameters and can be used for more varied effects. In fact each kind of liquid texture on each level can have a uniquely specified warp effect. One of the improvements allows the warp scale to be independent of the texture size so you can have 'waves' much bigger (or smaller) than the texture repeat. This should be useful on big expanses of water or lava.

Another thing which I'll open up is the 64x64 texture size limit on floors. The density will remain the same but applying a 128x128 texture to the floor will mean fewer repeats per unit of floor so more varied floors will be possible. They could be rotated too but only worthwhile if an editor makes this easy to specify (not so easy to view/test, perhaps!).

[dml]

Warp shader now complete. It accepts 8 constants which define warp parameters:

Code: Select all

 wave period (u)
 wave period (v)
 wave phase (u)
 wave phase (v)
 twist magnitude (u)
 slosh magnitude (u)
 slosh magnitude (v)
 twist magnitude (v)

...by combining these you can get a range of effects from sloshing waves to boiling lava, all at constant cost. The u,v axes are calculated independently and can animate at different speeds and with different period/magnitude. The magnitude can be bigger than a floor tile. The parameters are defined just once per renderstate and the rest is calculated per-pixel. Have not done the renderstate bit yet but that is less trouble.

Will put this aside now to focus on 2D stuff and integrate it later.

warpy.png

Not very clear from a screenshot, since it's an animated effect...

[dml]

A few short vids have been uploaded here to show this shader using same water texture but with different parameters. This doesn't show the full range of the shader but it does give some reasonable examples. The default water texture isn't too great so some imagination might be needed to fill in a replacement

https://dl.dropboxusercontent.com/u/12947585/BM/l5.avi
https://dl.dropboxusercontent.com/u/12947585/BM/l1.avi
https://dl.dropboxusercontent.com/u/12947585/BM/l2.avi
https://dl.dropboxusercontent.com/u/12947585/BM/l3.avi
https://dl.dropboxusercontent.com/u/12947585/BM/l4.avi

The shader affects all visplane surfaces at the moment - this is why the ceiling looks very weird.

I gave up optimizing the code at ~20 ops per pixel on the DSP side (with most x/y pipeline slots filled) overlapped with 3 CPU ops (for lighting lookup, or 2 ops for 'fullbright' shading). This is a huge win over the old CPU version which used lots of CPU ops per pixel :-z and was really only usable at half display resolution.

I can see another 1 or 2 DSP ops shaved off it without losing function but unless the CPU datacache causes issues on a real machine it's not worth the trouble - it takes a lot of effort to reshuffle the code just for one op. It could be trimmed by 20% or so if the parameters are dropped for a fixed function version (i.e. a single, inflexible effect).


I don't have any time left tonight to play with encoding so the vids are only a few seconds each to keep the files a sensible size.

[dml]

To make sure I didn't get further distracted with shaders, I made an effort last night to get the 2D weapon overlays to work in the game. This is far from 'done' but they do at least draw properly in truecolour and in the right place, on top of everything else.

weap.png

There are some problems left to solve, relating to optimizing it properly at all window sizes/resolutions, light levels, invisibility etc.

[bullis1]

You're progressing at break-neck speed

The liquid shader is really nice. Great work once again.

[Eero Tamminen]

I did a quick try with the latest code in hg repo and there are some small problems:

Weapons don't show fully, at least in in default RGB resolution, bottom part of them is missing, so it looks like the weapon comes up from floor.

Timedemos are again out of sync when doing default build. They would seem to work with "-timedemo" option, but as that's working much slower, it's not that good for profiling.

I think weapons switch might also be slightly slower than in real doom.

[dml]

Hi!

I did a quick try with the latest code in hg repo and there are some small problems:
Weapons don't show fully, at least in in default RGB resolution, bottom part of them is missing, so it looks like the weapon comes up from floor.

Yes there's a short note in one of the recent changesets about this:

Code: Select all

minor changes to center player weapon overlays on framebuffer window
todo: window scaling doesn't match Doom's overlay coords - need to pass window rectangle to BM instead of calculating from arbitrary scale value

...I know how to fix it but it requires some changes to BM API and calcs in video.s for viewport size, which are not done yet.

Timedemos are again out of sync when doing default build. They would seem to work with "-timedemo" option, but as that's working much slower, it's not that good for profiling.

I haven't noticed this - I ran a demo earlier today from current code. A particular demo or wadfile?

I think weapons switch might also be slightly slower than in real doom.

If TICRATE is set to 15 with scaling disabled (I think it is for the demo-compatible mode) then everything seems to happen in slow motion including player shooting.

[dml]

Eero, I meant to add - if you press the '+/-' key to change viewport/window size, you should find the full-height mode looks ok (size '10' i.e. the biggest window size with status bar still present).

The very largest size (11) for fullscreen is wrong because BM isn't expanding vertically from 168 to 200 lines, so the player's hand ends up on top of the status bar. The default window size is 9, which is a slightly reduced area with a border around it, and BM's window rectangle doesn't match Doom's expectation so the overlays end up in the wrong place.

So the only size that looks right currently is 10, and you'll have to hit '+' once to get that. The screenshot above was taken in that mode.

[dml]

With the 2D stuff started (but not finished) I'll be switching between that and audio/sfx work for the next week or two. The aim will be to have a very roughly complete game - despite rough edges - so the rest can be gradually finished off in no particular order.

I want to get the basics finished as soon as possible so I can spend some time doing 'Atari-fication' / enhancement work instead of endless porting drudge of which there is plenty in small pieces.

[kristjanga]

Doug should be nominated a nobel prize

[dml]

Sound is now working, with a hard-linked sound sample. I'll have to do a bit more to get Doom's SFX pulled into the resource cache and fix the other things that Doom is trying to do with sound.

Doom's SFX are nearly all 11025Hz so the Falcon will be playing them at 12292Hz to keep the cost down. It has been set up for 16bit stereo with 3 source channels (so 6 output channels) with pitch, volume and panning control. There is some optimization to do here but it looks ok for now. It should be possible to configure it for anything between 1 and 8 source channels (16 output channels) depending on hardware but 2 or 3 seems about right for a base 16MHz machine with those features and using the CPU.

The priority decay mechanism (suggested here some time ago) has been included so it still works quite well with just 1 or 2 source channels. The priorities are re-evaluated each audio frame so background sounds can pop to the front when foreground ones decay enough.

There is a facility for ambient/repeating sounds but no way to track/control them yet from Doom (I'm not sure there are any, in fact - something which can be added for sure).

Sound events are fed from Doom to the Falcon audio system through an interrupt-(thread?)safe non-blocking queue, and the system can insert up to 16 new events in a frame without waiting for anything. It can play up to 16 virtual channels with the highest priority subset reaching the Codec each audio frame.

I'm not sure about employing the DSP for mixing because of some problems with existing optimizations, particularly floor rendering. I don't really want to trade one for the other just now.

I haven't figured out how Doom specifies panning information (that area of the code is confusing with some relevant looking but half-written stuff disabled) so this feature isn't mapped yet. Pitch control is mapped and works ok.

Next step will be to get it playing the correct sounds and at the correct volume.

[dml]

Last night I had Doom loading samples from the wad via the BM resource cache, although they are not being managed so they could still get kicked out while a sample is playing. A bit more to do there.

It seems the game code tries to load all possible samples for all game types in advance (!) and keeps them statically locked (loading a default sample for any missing ones). I'm going to try to avoid that situation and just precache them, allowing them to be kicked out and pulled back in on demand. This will let me keep Doom's static memory claim as low as possible and hopefully reduce runtime memory use too.

Still only playing the hard-linked pistol sound but that should change next time I get to play with it.

[EvilFranky]

Doug,

How is the Falcon playing back the non standard frequency at the moment? Is it performing on the fly resampling or just playing the sample at a higher pitch for now?

Sent from my Nexus 4 using Tapatalk 2

[Eero Tamminen]

How is the Falcon playing back the non standard frequency at the moment? Is it performing on the fly resampling or just playing the sample at a higher pitch for now?

Based on how it sounds, I think it's just playing it at higher pitch. Iit's a bit hard to say because BM is a bit too demanding for Hatari on my machine, it runs constantly with high frameskip and that affects also sound...

(When I have more time, I guess I need to profile Hatari too, not just use Hatari to profile BM. )

[dml]

Doug,

How is the Falcon playing back the non standard frequency at the moment? Is it performing on the fly resampling or just playing the sample at a higher pitch for now?

Sent from my Nexus 4 using Tapatalk 2

It's resampling most of the time. There is a fastpath for sample channels which replay near the output frequency (12khz) but the game shifts pitch randomly anyway for added variety so a resampling path is needed for that (or lots of copies of the samples). Copies are ok for some stuff but I'd consider that a caching job if anything.

So it's a lot like a modplayer, designed more for SFX and panning/positional separation. The channel count isn't hardwired but I'll add some paths for combining channels in pairs or whatever for speed at the average channel count.

[dml]

It is replaying slightly fast at the moment - I set the 'assumed' base freq == replay freq so thats 12khz, although changing it to the proper value of 11025 will work fine also (and it should be changed).

[dml]

BM is playing samples from the resource cache now, so the game sounds mostly correct. Not everything completely right e.g. chainsaw has some funny hacks to deal with 'mode changes' and cancelling old sounds etc.. these things will need separate attention.

[EvilFranky]

Ok cool

Just wondered if you'd been looking at getting them manually re-sampled then re-added to the WAD.

Could have been an excuse to get some 'Falcon' enhanced sounds added

[dml]

Ok cool

Just wondered if you'd been looking at getting them manually re-sampled then re-added to the WAD.

Could have been an excuse to get some 'Falcon' enhanced sounds added

The player resamples continuously - but it should still be possible to override samples with files, in the same way it currently works for textures. i.e. they can be put in a WAD but they can be left as a raw filesystem too.

[EDIT]

more SFX are planned - although not so much replacing old sounds as adding extra ones.

[dml]

Iit's a bit hard to say because BM is a bit too demanding for Hatari on my machine, it runs constantly with high frameskip and that affects also sound...

It does run quite a bit faster if you build with -DTIMEBASE_CONTROL=3 (instead of =1) but then the PC demos don't work, and that isn't very helpful for you...

(When I have more time, I guess I need to profile Hatari too, not just use Hatari to profile BM. )

So long as you don't get involved in profiling the profiler you should be able to stay sane