Jump to content
IGNORED

Upcoming Virtual Jaguar 2.0.0 release


Shamus

Recommended Posts

What I wanted to ask is: "Is that normal?" :P

If you mean, are those icons really that ugly, then the answer is yes. :P Hopefully the tooltips and status line/toolbars/menu are all pretty self explanatory. :) BTW, I think this is a neat, if easily overlooked feature:

 

post-4305-0-03709000-1309121409_thumb.png

 

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. :D

Link to comment
Share on other sites

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. :D

 

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.

Link to comment
Share on other sites

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. :D

Edited by Shamus
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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. :P

 

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. ;)

Link to comment
Share on other sites

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. :D

 

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 by Shamus
Link to comment
Share on other sites

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! 8)

Edited by Shamus
Link to comment
Share on other sites

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! 8)

 

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

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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%.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...