Shamus Posted June 26, 2011 Author Share Posted June 26, 2011 What I wanted to ask is: "Is that normal?" If you mean, are those icons really that ugly, then the answer is yes. Hopefully the tooltips and status line/toolbars/menu are all pretty self explanatory. BTW, I think this is a neat, if easily overlooked feature: On the other hand, if you meant having to #undef main in every file that includes "SDL.h", then no, I don't think that's normal. Really, there shouldn't be any conflicts there but if there are, I'd like to know what's causing them and fix them, if possible. Quote Link to comment Share on other sites More sharing options...
ggn Posted June 26, 2011 Share Posted June 26, 2011 On the other hand, if you meant having to #undef main in every file that includes "SDL.h", then no, I don't think that's normal. Really, there shouldn't be any conflicts there but if there are, I'd like to know what's causing them and fix them, if possible. This is what happens when I comment out #undef main in src/gui/app.cpp g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -mthreads -Wl -Wl,-subsystem,windows -o debug/virtualjaguar.exe object_script.virtualjaguar.Debug -L'c:/msys/1.0/home/Administrator/vjdeps/Qt/lib' -lglu32 -lopengl32 -lgdi32 -luser32 -lmingw32 -lqtmaind `sdl-config --libs` -lz -Lobj -lmusashi -lQtOpenGLd4 -lQtGuid4 -lQtCored4 c:/msys/1.0/home/Administrator/vjdeps/Qt/lib/libqtmaind.a(qtmain_win.o): In function `WinMain@16': C:\\iwmake\\build_mingw_opensource\\src\\winmain/qtmain_win.cpp:131: undefined reference to `qMain(int, char**)' collect2: ld returned 1 exit status TBH I didn't know how to fix this (as usual), so I googled around and found this, which mentioned the fix. BTW I just checked, only app.cpp needs this #undef, the rest are quite happy with it missing. Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 26, 2011 Author Share Posted June 26, 2011 (edited) Thanks for the heads-up. I guess it makes sense that there would be a conflict there as SDL tries to wrap "main" for some reason. If the effect is benign, I might just stick the #undef in there for the next rev. Thanks for all your help! EDIT: Rolled the fix into r347. Edited June 26, 2011 by Shamus Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 27, 2011 Share Posted June 27, 2011 I just compiled r347 and the resulting executable will not run. It just crashes on start up. Exception Type: EXC_CRASH (SIGSEGV) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 1 Dispatch queue: com.apple.libdispatch-manager Thread 0: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x00007fff82605dd9 flockfile + 27 1 libSystem.B.dylib 0x00007fff8260fc80 vfprintf + 52 2 com.yourcompany.virtualjaguar 0x0000000100030c0a WriteLog + 154 (log.cpp:56) 3 com.yourcompany.virtualjaguar 0x0000000100007102 main + 98 (app.cpp:56) 4 com.yourcompany.virtualjaguar 0x00000001000069d2 _start + 224 5 com.yourcompany.virtualjaguar 0x00000001000068f1 start + 33 Thread 1 Crashed: Dispatch queue: com.apple.libdispatch-manager 0 libSystem.B.dylib 0x00007fff825cdc0a kevent + 10 1 libSystem.B.dylib 0x00007fff825cfadd _dispatch_mgr_invoke + 154 2 libSystem.B.dylib 0x00007fff825cf7b4 _dispatch_queue_invoke + 185 3 libSystem.B.dylib 0x00007fff825cf2de _dispatch_worker_thread2 + 252 4 libSystem.B.dylib 0x00007fff825cec08 _pthread_wqthread + 353 5 libSystem.B.dylib 0x00007fff825ceaa5 start_wqthread + 13 Thread 2: 0 libSystem.B.dylib 0x00007fff825cea2a __workq_kernreturn + 10 1 libSystem.B.dylib 0x00007fff825cee3c _pthread_wqthread + 917 2 libSystem.B.dylib 0x00007fff825ceaa5 start_wqthread + 13 Thread 1 crashed with X86 Thread State (64-bit): rax: 0x0000000000000004 rbx: 0x00000001032aee50 rcx: 0x00000001032aece8 rdx: 0x0000000000000000 rdi: 0x0000000000000004 rsi: 0x0000000000000000 rbp: 0x00000001032aee90 rsp: 0x00000001032aece8 r8: 0x0000000000000001 r9: 0x00000001032aee50 r10: 0x00000001032aee20 r11: 0xffffff80002e4730 r12: 0x00007fff70416998 r13: 0x00007fff70416d68 r14: 0xffffffffffffffff r15: 0x00007fff70416da8 rip: 0x00007fff825cdc0a rfl: 0x0000000000000247 cr2: 0x0000000105000000 EDIT: It appears to be a problem with the APP packaging. I opened the package, pulled out the executable and was able to run it manually. Running it as part of the package constantly crashes. Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 27, 2011 Author Share Posted June 27, 2011 What happens if you comment out the #undef main in app.cpp? Does it work then? If so, I have to do some conditional compilation. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 27, 2011 Share Posted June 27, 2011 What happens if you comment out the #undef main in app.cpp? Does it work then? If so, I have to do some conditional compilation. That fixed it. Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 27, 2011 Author Share Posted June 27, 2011 And so, on to r348. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 27, 2011 Share Posted June 27, 2011 And so, on to r348. Compiles properly on MacOS Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 27, 2011 Author Share Posted June 27, 2011 r349: Added a couple of options to be able to turn the BIOS and DSP on and off. @goldenegg: I'll bet when you first run this, the "Enable BIOS" checkbox will be unchecked. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 28, 2011 Share Posted June 28, 2011 r349: Added a couple of options to be able to turn the BIOS and DSP on and off. @goldenegg: I'll bet when you first run this, the "Enable BIOS" checkbox will be unchecked. You're right Options for both BIOS and DSP were unchecked. Now all the games which previously gave a black screen appear to work. Mutant Penguins seems to have some sound issues though, as sounds only intermittently play and have an echo to them. EDIT: The sound problem appears to be a general one. Even the audio for the BIOS is choppy. EDIT 2: Soccer Kid crashes VJ. When you load the game, nothing happens for about 15 - 20 seconds and then the crash occurs. I've attached the log to this post. soccerkid.txt Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 28, 2011 Author Share Posted June 28, 2011 Yup, the DSP gives choppy sound. If it were able to keep up with the video, it would be smooth as silk. I know because I hard-coded a routine to output the bytes going to it to a file, and the file sounded flawless. The problem with the DSP is that it takes up too much time to run in general, and spends most of that time in a spinlock. Part of how Aaron Giles was able to make the CoJag games run well with sound is because he hard-coded some spinlock detection into the CoJag drivers. But that would be difficult to do in a general way, and might end up costing more than it saved. It's another item on the TODO list. Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 28, 2011 Author Share Posted June 28, 2011 (edited) Soccer Kid crashes VJ. When you load the game, nothing happens for about 15 - 20 seconds and then the crash occurs. I've attached the log to this post. Unfortunately it doesn't tell much, other than the 68K tried to execute an illegal instruction. Probably the best way to figure out why these things aren't working is to use the built-in debugger--which is planned, but nonexistant at this point. I should mention that Soccer Kid probably isn't the only one that doesn't work, and there's no way we're going to get the compatibility anywhere near 100% with the 2.0.0 release. That's our yultimate goal, but we ain't there yet. The near-term goal for 2.0.0 is usability. Once it's out, then we can go ahead and break stuff willy-nilly again. BTW, I should mention that anyone planning to release binaries of the current SVN to please hold off until r350 to release, as I need to make sure that the various parts of the UI relate very clearly that it's an SVN build. Thanks for all your help, it's greatly appreciated. Edited June 28, 2011 by Shamus Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 28, 2011 Share Posted June 28, 2011 In the Preferences window, should the 'Controller' section do anything? Right now it just shows a picture of a controller and nothing really happens. I'm guessing the intent is to eventually use this to configure controller input? Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 28, 2011 Author Share Posted June 28, 2011 (edited) Yes, it should do something, but no, at the moment, it does nothing. The intent is to use it in configuring the keys, but I haven't quite gotten there yet. BTW, r350 has been committed; update, build, and release away, those of you who are intending to release binaries. Thanks again for all your help! Edited June 28, 2011 by Shamus Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 28, 2011 Share Posted June 28, 2011 BTW, r350 has been committed; update, build, and release away, those of you who are intending to release binaries. Thanks again for all your help! Any docs or extra files you want included with the binaries? EDIT: R350 won't compile. src/gui/about.cpp:20:21: error: version.h: No such file or directory src/gui/about.cpp: In constructor ‘AboutWindow::AboutWindow(QWidget*)’: src/gui/about.cpp:40: error: expected `)' before ‘VJ_RELEASE_VERSION’ make: *** [obj/about.o] Error 1 Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 28, 2011 Author Share Posted June 28, 2011 It's a prerelease, so I'd say no. With an official release, all documentation goes in. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 28, 2011 Share Posted June 28, 2011 See my edit above. Looks like version.h wasn't checked in. Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 28, 2011 Author Share Posted June 28, 2011 You need to use the main Makefile for that. Have you done qmake -set QMAKESPEC macx-g++ yet? You just have to do that once, qmake has a persistent storage mechanism for that stuff. Assuming that works, you should be able to use the main Makefile from now on. If not, run the main Makefile anyway, and the workaround will build the rest. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 28, 2011 Share Posted June 28, 2011 I've been using a 3 step compile process: qmake -spec macx-g++ virtualjaguar.pro make -f musashi.mak make If I try to do qmake -set QMAKESPEC macx-g++ make The compile fails as the makefile executes 'qmake virtualjaguar.pro -o makefile-qt' which results in the creation of a Xcode project called makefile-qt.xcodeproj EDIT: Sorry ... posted before I finished typing I can use the makefile to generate version.h, then clean and compile using the three step method after it fails. Quote Link to comment Share on other sites More sharing options...
Shamus Posted June 28, 2011 Author Share Posted June 28, 2011 That's very strange as the Qt documentation says that that should change the default from making xcode to making makefiles, without any further intervention. Will have to do some more investigation. But in the meantime, if you change the line in the main makefile (the makefile from the VJ repository that is!) from qmake virtualjaguar.pro -o makefile-qt to qmake -spec macx-g++ virtualjaguar.pro -o makefile-qt it should work in one step. Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 28, 2011 Share Posted June 28, 2011 Here's the MacOS binary for r350. NOTE: This binary is for Intel only! virtualjaguar-macOS-r350.zip Quote Link to comment Share on other sites More sharing options...
goldenegg Posted June 28, 2011 Share Posted June 28, 2011 That's very strange as the Qt documentation says that that should change the default from making xcode to making makefiles, without any further intervention. Will have to do some more investigation. But in the meantime, if you change the line in the main makefile (the makefile from the VJ repository that is!) from qmake virtualjaguar.pro -o makefile-qt to qmake -spec macx-g++ virtualjaguar.pro -o makefile-qt it should work in one step. I can confirm that change works 100%. Quote Link to comment Share on other sites More sharing options...
Tyrant Posted June 28, 2011 Share Posted June 28, 2011 The problem with the DSP is that it takes up too much time to run in general, and spends most of that time in a spinlock. Part of how Aaron Giles was able to make the CoJag games run well with sound is because he hard-coded some spinlock detection into the CoJag drivers. But that would be difficult to do in a general way, and might end up costing more than it saved. It's another item on the TODO list. A spinlock where? Waiting for bus time or waiting for PITs to fire? Also I think you mean tight loop rather than spinlock, which has a very specific meaning. Quote Link to comment Share on other sites More sharing options...
ggn Posted June 28, 2011 Share Posted June 28, 2011 Here's a R346 for Windows. Please note that because of all the supporting DLLs (most notably QT), it's a pretty hefty size Quote Link to comment Share on other sites More sharing options...
Tyrant Posted June 28, 2011 Share Posted June 28, 2011 Here's a R346 for Windows. Please note that because of all the supporting DLLs (most notably QT), it's a pretty hefty size If you rebuild Qt statically linked, it'll make statically linked versions of anything it builds too, meaning no need for extra DLL's. I really wish there was a flag at compile time to make it do that, but it seems the only way is to rebuild all of Qt statically first. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.