Ouchface
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > C-only source port...
Pages (2): « 1 [2]  
Author
All times are GMT. The time now is 02:16. Post New Thread    Post A Reply
Eponasoft
Member


Posts: 452
Registered: 07-09
Yeah, that solved the issue of friend_distance. Still crashes of course, but I haven't had the chance to go through the code yet.
Old Post 09-02-09 11:22 #
Eponasoft is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 6000
Registered: 07-00
Eponasoft said:
Graf, the problem spot takes place less than 0.2 seconds after typing "run" in gdb. So unless it can be broken before that, that's not going to help too much.
Use the "break" command before you type "run"?
Old Post 09-02-09 12:14 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Eponasoft
Member


Posts: 452
Registered: 07-09
fraggle said:
Use the "break" command before you type "run"?

Had no effect.
Old Post 09-02-09 21:46 #
Eponasoft is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
fraggle
Super Moderator


Posts: 6000
Registered: 07-00
I assume you specified a function to break on? :-)
Old Post 09-02-09 21:49 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Eponasoft
Member


Posts: 452
Registered: 07-09
Yeah...I set the break point for function TryRunTics. It reaches the function, then locks up...just as it did when not using break and reaching the segfault.

EDIT: Running gdb without X running is much more effective...I'll try as much as I can from the normal console without X.
Old Post 09-02-09 22:42 #
Eponasoft is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Eponasoft
Member


Posts: 452
Registered: 07-09
Good ole pen n paper. :) Running from the normal console without X running helped a lot. Results as follows:

code:
327    while(SDL_PollEvent(&event))
(gdb) step
0x281a5db0 in pthread_rwlock_unlock() from /lib/libthr.so.3
(gdb) step
Single stepping until exit from function pthread_rwlock_unlock, which has no line number information.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x280fb528 in ?? () from /libexec/ld-elf.so.1
(gdb) step
Cannot find bounds of current function
Old Post 09-02-09 22:56 #
Eponasoft is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 4615
Registered: 08-00
You're already outside the program code at that point. That means whatever went wrong happened earlier than you are thinking. At this point I am going to suggest that you need to step through the entire initialization process, starting from main. That's a lot of code to trace, but I don't see any other way to do it.

Also SVN revision 17 is now up, so I recommend updating to it. It includes a fix to the DOGS issue and some more warning fixes.
Old Post 09-03-09 00:03 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Eponasoft
Member


Posts: 452
Registered: 07-09
I got the latest source and will build and test as you suggested.

I am noticing that this problem still exists:

code:
p_floor.c:913: error: conflicting types for 'EV_DoElevator'
p_spec.h:888: error: previous declaration of 'EV_DoElevator' was here


p_spec.h lists this as

code:
int EV_DoElevator(line_t *line, ceiling_e type);


I am pretty sure p_floor.c has the correct argument list:

code:
int EV_DoElevator (line_t* line, elevator_e elevtype )


Another one is this:

code:
p_mobj.c:720: error: static declaration of 'itemrespawnque' follows non-static declaration
p_mobj.h:373: error: previous declaration of 'itemrespawnque' was here
p_mobj.c:721: error: static declaration of 'itemrespawntime' follows non-static declaration
p_mobj.h:374: error: previous declaration of 'itemrespawntime' was here

I think I mentioned this one previously...going by the original source code, neither of these two variables are static. Same with this:

code:
r_segs.c:48: error: static declaration of 'segtextured' follows non-static declaration
r_bsp.h:39: error: previous declaration of 'segtextured' was here
r_segs.c:49: error: static declaration of 'markfloor' follows non-static declaration
r_bsp.h:40: error: previous declaration of 'markfloor' was here
r_segs.c:50: error: static declaration of 'markceiling' follows non-static declaration
r_bsp.h:41: error: previous declaration of 'markceiling' was here
r_segs.c:64: error: static declaration of 'rw_x' follows non-static declaration
r_bsp.h:37: error: previous declaration of 'rw_x' was here
r_segs.c:65: error: static declaration of 'rw_stopx' follows non-static declaration
r_bsp.h:38: error: previous declaration of 'rw_stopx' was here
Old Post 09-03-09 02:26 #
Eponasoft is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
andrewj
Senior Member


Posts: 1380
Registered: 04-02
Does the crash still happen if you disable sound (-nosound option) ?
Old Post 09-03-09 03:02 #
andrewj is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Eponasoft
Member


Posts: 452
Registered: 07-09
andrewj said:
Does the crash still happen if you disable sound (-nosound option) ?

Wow, good call. The crash does NOT happen if this option is used, and the game will start up normally. So then...the problem is likely somewhere in the sound code...guess this will take some poking around the sound modules. :D

EDIT: I believe the actual source of the issue lies in S_ChangeMusic in s_sound.c. I once again used some debug printfs to track program flow, and noted that it crashed after S_ChangeMusic was called by S_StartMusic. So I terminated S_ChangeMusic early, and I was able to start the binary with sound enabled; just with no music (samples play fine). Of course, it segfaulted on exit, but that's not a problem; some tinkering with the exit code will fix that. Furthermore, since this has been for a new game engine that is not going to use the MUS files to begin with, I can rip out that code altogether anyways and replace it with normal SDL_mixer code. My game uses .mod and .ogg soundtracks, so this will work out great. :)

Thanks to everyone who has helped out with this so far, I really appreciate it. This can now be considered a victory. :)

EDIT2: The segfault on exit was caused by Mix_CloseAudio();. I've had this problem in my own SDL-based applications as well. Commenting out that line stops the segfault on exit.

EDIT3: Though this is against the natural order of the DOOM source code, I added SDL_mixer to s_sound.c and just put in the alternate music code there. It made more sense than to put it into i_sound.c since s_sound.c is where the S_ChangeMusic function is. As a test of the modified sound routine, I added Sycraft's DOOM soundtrack to the game (downloaded from the Vavoom webpage), and it sounds simply awesome. :)

Last edited by Eponasoft on 09-03-09 at 06:25
Old Post 09-03-09 04:23 #
Eponasoft is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Quasar
Moderator


Posts: 4615
Registered: 08-00
While I appreciate that you're making it work, the way you've gone about it is not helpful as far as getting this stuff fixed in my codebase :/
Old Post 09-03-09 21:26 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Eponasoft
Member


Posts: 452
Registered: 07-09
Well, the whole point was to find a basic engine to use as a codebase for my own game, as my game's technical requirements exceed that of DOOM. However, there are a few things in the code that I commented on in earlier posts that will help correct existing issues, such as ill-placed statics and incorrect function arguments. I honestly have no idea as to how to make the music functions work, though I can take a closer look at i_sound.c and see if there are any issues there that can be corrected. I will copy the modified files to my project directory, and keep a "clean" copy in ~/winmbf that I can tinker with and help to improve the codebase. It is really no surprise to me that MSVC++ does not complain about the existing issues in the codebase...it's always been a quirky, lenient compiler that doesn't want to work too hard so it passes over certain potential issues that a proper C/C++ compiler would bail on. mingw would likely complain if this code was run through it. But anyways, I will move that code out now and put in a clean copy, then submit to you some modifications that will help to improve the game engine.

EDIT: By the way, I would consider a name change...since this code can be easily made cross-platform, I would suggest you change it to something more appropriate, such as sdlmbf. Winmbf is an ok name, but something that doesn't imply Windows-only would be better. NeoMBF, SDL-MBF, etc...

Last edited by Eponasoft on 09-03-09 at 23:56
Old Post 09-03-09 23:18 #
Eponasoft is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Eponasoft
Member


Posts: 452
Registered: 07-09
Well OK, here's some updates to the source code. Note that I normally don't do the whole SVN thing, nor am I really much of a "team player", so to speak...but hopefully this will help a bit. Mainly what this all fixes is the incorrect statics and function parameters, changes a header declaration, and does some platform-specific function substitutions. I also included a makefile for FreeBSD. I do not have a Windows compiler to test the changes out on, and I made sure to not alter anything that would be Windows-specific. The only exception is in d_io.h, where the TRUE and FALSE declarations are; I'm not sure if the changes I made there will make any particular compiler cry so you might want to verify that particular change. Also, I have not tested the specific changes for the -cdrom option, but the original code failed to build here due to an incorrect number of parameters on mkdir; doing this on a UNIX system is considerably more detailed than in Windows or DOS, and that seems especially true for BSD-based systems. I did a partial rewrite of that section. Finally, O_BINARY and strlwr are missing from the BSD libraries, so I filled them in.

I ran this through make here on my FreeBSD box and it compiles perfectly without even a single warning. So now I have winmbf for FreeBSD, hehe. :) Of course, I have to run it with -nomusic for now, but I will look deeper into i_sound.c when I get the chance to see what kind of changes can be made to make it function better.

So then, the updated source:
http://www.nodtveidt.net/updatedsource17.zip
Old Post 09-04-09 00:34 #
Eponasoft is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
Eponasoft
Member


Posts: 452
Registered: 07-09
Well, so far I've been able to correct the segfault on exit with music disabled...was a pretty easy fix, really. i_sound.c seems pretty straightforward, so I don't know exactly what could be the problem here...it might be in another module, and my guess is mmus2mid.c. Of course, it could be my system itself...this system has no MIDI device. In Windows, the MIDI device is emulated, but here, no such emulation is installed. I'm told that some source ports use timidity for music...is that the case here?

By the way, I recorded a demo but it failed to play back, citing this error:

code:
R_FlatNumForName:   not found

Any suggestions?
Old Post 09-04-09 21:15 #
Eponasoft is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
andrewj
Senior Member


Posts: 1380
Registered: 04-02
I think the music problem is just because SDL_mixer is a piece of crap.

Dunno about the demo problem, try renaming the demo file.
Old Post 09-05-09 01:30 #
andrewj is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 7046
Registered: 07-07
andrewj said:
I think the music problem is just because SDL_mixer is a piece of crap.

SDL is crap more generally, at least on Windows platforms; I suppose it's not that bad on Linux or nobody would still use it.
Old Post 09-05-09 09:50 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Eponasoft
Member


Posts: 452
Registered: 07-09
As far as I know, SDL in Windows is simply a frontend for various components of DirectX. SDL_mixer is essentially a frontend for libmikmod (ewww). For Unices, SDL is pretty good overall...you can always just use OpenGL though. Not a lot of options, really...you can use Xlib directly (MAJOR headache, trust me on this one...), or use something like svgalib or grx. A lot of applications in the Unix world use libmikmod though...even some high-end X apps like XMMS (of course, it also uses that icky Motif-style interface...gross!).
Old Post 09-07-09 14:27 #
Eponasoft is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit/Delete || Quote
andrewj
Senior Member


Posts: 1380
Registered: 04-02
GLFW is another option for OpenGL apps. (Note there is no such thing as "just OpenGL" because OpenGL does not have any mechanism for setting video modes, creating windows or getting input).

I haven't tried GLFW yet. Think on Linux I will stick with SDL, as it has always worked well for me there (and fairly well on WinXP too).
Old Post 09-07-09 14:53 #
andrewj is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
Gez
Why don't I have a custom title by now?!


Posts: 7046
Registered: 07-07
Eponasoft said:
As far as I know, SDL in Windows is simply a frontend for various components of DirectX.

A bad frontend. A crap frontend. ZDoom on Windows uses DirectX directly (heh) and is all the better for it. For example, DirectInput. ZDoom does support non-QWERTY (US) keyboards. All the SDL-based ports out there do not. ZDoom does support mouse buttons past the fourth. All the SDL-based ports out there do not. ZDoom does recognize a keypad key as what it is. All the SDL-based ports out there think they're all numlock.
Old Post 09-07-09 15:03 #
Gez is offline Profile || Blog || PM || Search || Add Buddy IP || Edit/Delete || Quote
All times are GMT. The time now is 02:16. Post New Thread    Post A Reply
Pages (2): « 1 [2]  
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Source Ports > C-only source port...

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts 		HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.

Forums Directory