natt

D_RUNNIN OR BUST

If you're talking about fluidsynth as it's used in zdoom or prboom-plus, then no, no problem. In those cases, everything is handled inside the application itself. The problem comes when you try to use system midi output.

md5 the iwad for starters

I always thought the "eraser" style mouse was half decent for fpsing; it's actually not all that different than the thumbsticks that console players use. And it can easily be integrated into a small package like a handheld gaming console. Unfortunately, tablet designers don't have me pre-approve their designs.

Well, I'll tell you what I concluded. Perhaps you already know all this though. In d_main.c:D_Display, we have the following sequence of calls if we're wiping case (lots of other stuff has been omitted): wipe_StartScreen() <draw lots of shit for the next tic> M_Drawer() NetUpdate() wipe_EndScreen() <wipe loop> The <wipe loop> morphs from the screen captured by wipe_StartScreen() to the screen captured by wipe_EndScreen() while continually calling M_Drawer() along the way. It does this by alpha blending and modifying the current screen, which is also the screen that M_Drawer() draws to. So in order for the loop to finish successfully, what M_Drawer() puts on the screen during the loop must be the SAME as what it put on to the screen right before wipe_EndScreen(). But here's the problem: if you look at the ways the stuff drawn by M_Drawer() can change, you'll find that NetUpdate() does in fact change it: NetUpdate() -> D_ProcessEvents() -> M_Responder() and M_Responder() can change the position of the sigil (which menu item it's pointing to). So the M_Drawer() call inside the wipe loop draws the sigil in a different place than the "target" screen, stored by wipe_EndScreen(), so the wipe never finishes. Swapping lines 359 and 360 of d_main.c, NetUpdate() and M_Drawer(), seems to work, as expected.

no wait i just figured it out

My guess would be some sort of backbuffer/frontbuffer discrepancy? I'm not terribly familiar with the chocolate strife codebase.

Here's the deal (I think). f_wipe.c:wipe_doColorXForm has a very "fragile" detection of its end condition; it simply keeps on combining colors until it gets to an iteration where everything matches end_screen. I can pretty reliably reproduce the crash if I simply scroll (hold DOWN) over the "new game" entries when the wipe occurs. And in situations where it does crash, I see something like this frozen in space: http://img703.imageshack.us/i/strifecrash.png/ I managed to catch the menu cursor in two places at once. This leads me to believe that the problem is that the interference of M_Drawer () is leading to the finish condition in wipe_doColorXForm never being reached. Recompiling with the call to M_Drawer () commented out, I find that I can no longer reproduce the crash. I think it has something to do with the location of the cursor being different on the "wipe from" and the "wipe to" screens and M_Drawer () continually redrawing it in the wrong place, but I can't be sure. Edit: IWAD verified as correct 2fed2031a5b03892106e0f117f17901f

The "empty slot no name" is a red herring. I'm getting the crash even without entering a name, and sometimes not while putting in the name. It's definitely happening at that first crossfade though. I'll tell you if I figure out any more. edit: did more gdbing. d_main.c:386 done = wipe_ScreenWipe(wipe_ColorXForm , 0, 0, SCREENWIDTH, SCREENHEIGHT, tics); This never returns true. This can be traced to f_wipe.c:wipe_doColorXForm never returning 1.

As best as I can tell, it goes something like this: Start the executable, quickly select new game, hit enter twice on an empty slot (nothing will happen), and then wait for the "intro sequence" to begin. At that point, it stops responding; GDB shows it's stuck in the do loop at d_main.c:375. Couldn't tell you more than that.

That sounds right, but I know better than to trust myself on those sorts of things.

I think both of these are workable solutions, but I doubt either would hold up to the rigors of demo sync, which would mean another demo compatibility option bolted on.

That means you're trying to load a PWAD as a demo. Reread the docs and make sure you're using the right command line parameters. Edit: btw, Unknown demo format 73 means you're trying to play an IWAD as a demo, in case anyone comes across it.

@echo off set /p params=Enter parameters to prboom-plus: prboom-plus %params% Slap that crap into a .bat file or something. Really just easier to use the command prompt though; the command history can be useful.

Grabbed SVN, compiled under mingw+msys with few warnings, and runs without crashing. I was never a very big fan of Strife so I didn't play much, but this does look like an awesome project. BTW: Crash if you try to start a new game with no name (ie, choose save slot, then hit enter twice without typing in a name)

Considering that I made a post which described the exact specifics of the problem down to source code excerpts, then yes I'd say you missed it. I'll reiterate in condensed form: Regardless of how the blockmap structure is stored, blockmap functions will cease to operate properly more than 32k units from the blockmap origin (in either x or y direction) because of an overflow in fixed_t arithmetic which is calculating position deltas from the blockmap origin. This gives a hard mapsize limit of 32k by 32k square outside which there will be no functional blockmap even with a correctly done limit-removing blockmap. And no, I don't advocate trying to fix this limit; just understanding it.

I'm not sure what you're saying; building a correct limit-free blockmap doesn't fix this.

There's a long standing problem with midi out and volume on various systems. There's no good portable concept of "master volume" for midi. As far as pausing goes, SDL_Mixer has problems pausing midi; I believe the usual workaround is to use volume to silence it. But if that doesn't work, then you're totally hosed. Given the history of SDL_Mixer, I doubt there's a resolution to be had. They don't seem to move too fast in fixing things.

I agree with you. I'm pretty sure SDL_Mixer doesn't implement any of the apogee stuff, and I know for sure that the midi code I wrote doesn't.

Now I feel like an idiot. I can't help but thinking I'm the only one who didn't know about this limit because it's so obvious once you see it... but I don't think I've ever seen it mentioned before? The code to convert x, y to blockmap index looks something like this and is repeated many times: fixed_t x; // coordinates you want blockmap index for fixed_t y; fixed_t bmaporgx; // (fixed point) blockmap origin, initiated at level load time fixed_t bmaporgy; #define MAPBLOCKSHIFT (FRACBITS+7) // p_maputl.h int bx; // blockmap indices you're going to make, hopefully between 0 and bmapwidth/bmapheight int by; bx = (x - bmaporgx) >> MAPBLOCKSHIFT; by = (y - bmaporgy) >> MAPBLOCKSHIFT; The problem is, (x - bmaporgx) is a fixed point, so its limited to -32768..32767, so you can't go more than that far from the blockmap origin without causing problems. When you fix it like this:bx = (unsigned) (x - bmaporgx) >> MAPBLOCKSHIFT; by = (unsigned) (y - bmaporgy) >> MAPBLOCKSHIFT; You break checking on the "wrong side" of the blockmap origin, which fails anyway (if bx < 0 or by < 0, you abort because there's no blocklist there), and you fix checking on the "right side" of the blockmap origin up to 65535 units away in either direction. Tested in prboom-plus, fixes all problems at the north end of europe.wad. God knows what compatibility problems it causes... patch against prboom-plus svn 4004 http://pastebin.com/TWPHChUv edit: btw, this patch causes some other problems, but that's not really an issue, because I just made it to demonstrate the limit; I don't think it's worthwhile trying to fix this.

The extents of the map are as follows: X: -11200..15968 (27168) Y: -18592..19168 (37760) The broken area of the map exactly corresponds with limiting the blockmap to 32768 units in the Y direction, but keeping the same origin. ie, Y: -18592..14176 is ok; Y: 14176..19168 is broken. But where does such a limit come from? Prboom-plus does not use the internal blockmap in this case; it builds its own. All of the indices in that internal blockmap are 32 bit. Also, the generated blockmap appears to be correct: Spot check: by = 260, bx = 109, list: 0 9932 9929 9927 9926 9923 -1 Note that this block is in the "broken" area. So I'm pretty sure the calculation failure is somewhere else, and the blockmap is in fact fine (when generated on the fly by prboom).

I assume this is for your community chest map? I'm not very familiar with the project, but isn't one of the requirements using nothing beyond the basic boom featureset? If that's the case, then you should really stay away from apogee emids. Preprocess them to regular arse mids first.

I'm not saying that you might not crash vanilla for some reason with a 400 pellet ssg, but I'm not aware of any particular limit that applies there.

http://doom.wikia.com/wiki/WAD Good place to start with the basic format. This document also has a lot both about the basic format as well as individual lumps: http://www.gamers.org/dhs/helpdocs/dmsp1666.html As far as autodetect, good luck on that. You might start by saying things like "well, if it's got ExMy, it's Doom; if it has MAPxy, it's Doom2", but what about Heretic? And what about source ports that support non-standard map lump names? So for the former, you start scumming through the maps for texture names or thing types, and for the latter, you start parsing things like ZDoom's MAPINFO lump. To differ between doom2 and tnt/plutonia, you have to get into texture stuff as well. I'm sure you could make a basic iwad detector rather easily, but you could spend quite a long time on edge cases and whatnot.