doombringa

Thx, but no luck. I got SDL WIi revision 88 with "svn co -r r88 http://sdl-wii.googlecode.com/svn/trunk/" and built it. "make all" didn't work, because sdl_gfx complained that there's no SDL.h, so I used "make" followed by "make install" seperately in each folder, which should be okay? (I deleted all r89 files in my devkitpro folder manually before building r88.) Then I tried building WiiDoom with both libogc r4165, and after that, I extracted the "normal release" libogc-1.8.3.tar.bz2 into my devkitppc folder, overwriting r4165 for a second try. The size of the boot.dol this time around was 2.199.648 bytes and 2.198.944 bytes respectively. The latter one is pretty promising, but I still got the usual code dumps with both. This is really weird, by now I should have the exact same libraries that you've used. But I don't want to give up yet. I guess you used Linux and Eclipse to build WiiDoom? Could you pls tell me the exact version of your OS and IDE? I suppose that if I replicate your build environment, there's no reason I shouldn't be able to get it working. @Hyper_Eye: Debugging my boot.dol sounds like a good idea, that's propably what I'll have try if everything else fails. Though I'm not familiar with Wii development, so that could prove to be quite difficult for me.

That didn't do it either, I got another lovely codedump. The new boot.dol got a little bigger this time around though (2.199.680 bytes). Would it help if I post the sizes of my freshly built libogc r4165 libs? How about getting the devkitpro r4165 sources and building that one from scratch as well?

Thank you for your quick reply. I got SDL Wii r89 from http://sdl-wii.googlecode.com/svn/trunk/ and built the libs. Here's what I got: libSDL.a size: 1.740.070 bytes libSDL_gfx.a size: 421.352 bytes libSDL_image.a size: 396.782 bytes libSDL_net.a size: 60.106 bytes libsmpeg.a size: 1.299.678 bytes libSDL_mixer.a size: 1.705.838 bytes libSDL_ttf.a size: 124.352 bytes The new bool.dol is almost the same size as yours, but still not quite: 2.198.976 bytes vs 2.199.040 bytes. The problem is that it still crashes with a code dump at the exact same moment. Almost there.. maybe there's something else I'm missing?

I'm running WinXP SP2 32bit and used the devkitProUpdater-1.5.0.exe to install the following packages into c:/devkitpro: msys-1.0.11-RC2.exe devkitPPC_r21-win32.exe libogc-1.8.3.tar.bz2 libfat-ogc-1.0.7.tar.bz2 Then I downloaded the following packages manually and extracted them to "c:/devkitpro/portlibs/ppc": expat-2.0.1-ppc.tar.bz2 freetype-2.3.11-ppc.tar.bz2 jpeg8a-ppc.tar.bz2 libpng-1.4.1-ppc.tar.bz2 mxml-2.6-ppc.tar.bz2 tremor-lowmem-ppc.tar.bz2 zlib-1.2.4-ppc.tar.bz2 Then I downloaded "SDL Wii 11-28-2009.zip" and extracted it into c:/devkitpro (it already included a libogc directory). Finally, I downloaded the WiiDoom source with Mercurial 1.6. I opened up msys, moved to the wiidoom directory and wrote "make". Despite many warnings, it seemed to compile and link fine, resulting in a boot.dol of 2.214.144 bytes (not quite the same size as the precompiled one available for download). I then copied the boot.dol to my SD card, overwriting the original, file. When I start the game via homebrew channel, I can choose to load the DOOM1 wad file, but after clicking "start", I get a DSI exception and a stack/code dump. Any idea what I might be doing wrong?

Big thx for your explanations. I'll take a look at the ZDoom fix. Now, what about these splats not appearing on floors and ceilings, is there a fix for that as well?

When using freelook and no autoaim, I found that puffs are spawned too low when your shots get up to a certain point near the ceiling. The puffs stay at a certain height, even if you aim higher and higher. Eventually, they start gaining in height again and appear above the wall, but way below your aim. There are no such issues with floors, as far as I can tell. This happens in every source port with freelook that I tried so far (ZDoom, GZDoom, Legacy Doom, Eternity Engine). The displacement is easily visible, if you use a crosshair and splats. The problem disappears, if you change the graphic options to use particles instead of sprites for puffs. I guess this isn't really a bug, because I assume that Vanilla Doom just doesn't need to display puffs high up on walls, close to the ceiling. I do wonder why none of the source ports changed this, instead of comming up with an entirely different solution (particles). Would it be too hard to spawn the puffs at the exact same locations as the particles? (And btw, why aren't splats drawn on ceilings and floors at all?)

Well, I would've tried to follow the ZDoom instructions on how to compile with MinGW, or is that not a possibility with GZDoom?

@Graf Zahl: So it is not meant to be build it on Windows even though they included a VC6 project file? This is really weird, because the remood project file looks similar, and that almost compiles with VC6 (gives hundreds of warnings and only a few errors). I guess I would have to build the Windows version on Linux then, or does Doom Legacy compile with MinGW? I wanted to write a hack for Doom and I figured it might be best to get a basic understanding of the source code first. So I started with modifying Chocolate Doom, because that is probably the most "uncluttered" engine and damn easy to build (only needs SDL). After looking at the source and taking notes, I was able to get a protoype running in a few hours, sadly it didn't work that well. At this point it might be a good idea to briefly explain what kind of hack it is. I always wanted to know what it would be like to play an FPS with a lightgun, and Doom seems to be the perfect candidate to try that out. So I deactivated mouse centering and movement, grabbed the mouse position, and changed a few functions to allow shooting at the direction you're pointing at. It wasn't perfect (I have problems calculating the correct bullet slope, maybe due to the software renderers nonexistent perspective correction), but good enough to hook up my Lightgun and try. Sad thing is, it doesn't work in fullscreen mode and it's not much fun in a 320x200 pixel sized window. So now I'm trying to compile other engines and see if I have more luck. Doom Legacy seemed like a logical next step, because Doom Wiki lists OpenGL in addition to a software renderer, and I could just port my hack over quickly, as the source ocde is pretty similar to that of Chocolate Doom (it looks like the original Doom C sources with only a few additions here and there). But now that it's giving me so much trouble, I may skip it and try GLBoom+, Vavoom or GZDoom. (Which I think you are the writer of? Nice job.) GZDoom isn't higher up on my list, because it seems to be a complete rewrite in C++ with tons of added features, which could make understanding the source harder. I also didn't find a tutorial on how to compile under Windows, but I guess I could use the one on the ZDoom Wiki as a guidance. @Gez: Yes that is a good idea, but as said remood is giving me errors (probably nothing that couldn't be fixed), the music either doesn't play at all (08a) or too fast (1027), and according to Doom Wiki it seems to have dropped the OpenGL renderer?

If you read the wLegacy.dsp I linked it says:CFG=DoomLegacy - Win32 Debug !MESSAGE This is not a valid makefile. To build this project using NMAKE, !MESSAGE use the Export Makefile command and run !MESSAGE !MESSAGE NMAKE /f "wLegacy.mak". !MESSAGE !MESSAGE You can specify a configuration when running NMAKE !MESSAGE by defining the macro CFG on the command line. For example: !MESSAGE !MESSAGE NMAKE /f "wLegacy.mak" CFG="DoomLegacy - Win32 Debug" !MESSAGE !MESSAGE Possible choices for configuration are: !MESSAGE !MESSAGE "DoomLegacy - Win32 Release" (based on "Win32 (x86) Application") !MESSAGE "DoomLegacy - Win32 Debug" (based on "Win32 (x86) Application") !MESSAGE And when I click build I get this error:--------------------Configuration: wLegacy1 - Win32 Debug-------------------- Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. NMAKE : fatal error U1052: file 'wLegacy.mak' not found Stop. Error executing NMAKE. wLegacy1.exe - 1 error(s), 0 warning(s)

Hello everybody, I tried to build the Doom Legacy 1.42 sources with Visual Studio C++ 6.0, but I'm having some probs. I'm not yet familiar with Visual Studio as I've only used MinGW so far, so I guess I'm just missing something simple here. This is what I do: -when I select "Open Workspace" and choose wLegacy.dsw, nothing happens -when I open the wLegacy.dsp file directly, I get the following message in which I click "yes" -after that I get this one, I continue with "ok" -now it prompts me to save a wLegacy1.dsp file, which I do -the workspace opens up and I choose "Export Makefile" -but then nothing happens, Visual Studio doesn't seem to create the .mak file (at least not in the folder where the .dsp file resides) Btw these are the two dsp files I'm talking about : http://www.filedump.net/dumped/wlegacy1266005826.txt http://www.filedump.net/dumped/wlegacy11266005884.txt Does anyone know where the problem lies?