22/12/2010 @19:45:43 ^20:52:38
gifs
Recently I hacked a thing into rboom to take screenshots of every frame of the player view. I don't usually bother posting about rboom stuff because it's not public but this time I have something to show for it. Screenshotting every frame naturally lends itself to making animated gifs.
- This is what the overdetailed map cheat looks like during a demo
- What happens when you don't have exactly the same map geometry on either side of a silent line teleporter
- An improved water texture (I didn't make the texture, just took screenshots of it)
- The rising slime in a donut sector looks ominous, but where does it go at the end?
- But if the slime disappears instantly as the floor comes through it, it looks boring.
bugger this (again)
I improved Bugger This a little
- The switches are now (slightly) visible from range, by having a tall, thin column of blood above them. These disappear when pressed.
- Added a more satisfying exit; the map now crushes a boss brain, with all the screaming that entails. Also, the player dies when it explodes.
Funnily enough this led to two compatibility fixes in, of all things, ZDoom. Firstly it was not handling negative thing angles the same way Boom does*, and also, floor crushers didn't hold in place until the thing they are crushing is dead.
Thanks to The Green Herring and gggmork who both managed to record demos beating it on Ultra-Violence. So it's not impossible after all!
The first of these demos led to some interesting messing about, as I will go on to describe.
* although arguably negative thing angles are illegal, indeed you shouldn't use anything not of the form { 45n | n=0..7 }
demo hacking
Suppose you record a demo of a single map where you die and restart a few times. Usually when recording if you die you quit the game and restart the recording. You can't just cut out the good part of the demo after all the deaths and expect it to sync.
What if you can? It turns out it's possible, at least with Boom demos, since the Boom demo format stored the random number seed in the header.
- find the state of the random number generator at the point you want
- find the random number seed that generates this state
- put it in the demo header
- chop out the tics up to the start of the successful run.
It does work! The first part is easy since you can just print it out. Editing a demo is pretty easy as well with a hex editor. The tricky part is finding the right random number generator; I couldn't think of a better way than just brute-forcing it, but there are "only" 2^32 possible values to check and it doesn't take that long to loop over them all.
I can't be bothered to write up the precise technical details. But I'm sure this stuff or something like it could be useful for tool-assisted demo recording, if I can find a way to make it easy to use (yeah right!)
