First Qt build (no emulation yet)

[TheCloudOfSmoke]

Yes, the post that I directly replied to when I stated my problem.

[Clements]

I get the same message, probably due to not having the MSVC 2008 runtime package installed on my system.

[mudlord]

I'm uploading the complete MSVC2008 runtimes to the server. Installing that should hopefully nullify the error.

EDIT: Uploaded. They are in the same location as the Qt4 DLLs

[Spacy]

Ah, that should be the problem. I just launched Dependency Walker again, and I made the mistake to just include MSVCR90.DLL. I should have looked deeper into the dependency tree and I would have found out, that the Qt DLLs themselves need the CPP-Runtimes as well. (Lol, I was even wondering why I didn't need the CPP-runtimes xD).

I will upload the full corrected package ASAP.


Edit:
OK, the corrected archive is up: http://vba-m.ngemu.com/vbam/vbaother...vba_qt_dlls.7z

There's also a msvcm90.dll in my redist folder, but it's really not needed, so I didn't include it.


Edit2:
Current build: http://vba-m.ngemu.com/vbam/vbaother.../vba_qt_385.7z
Now saves settings to INI file (currently toolbar/sidebar placement and translation).

[MNK]

Of the boring things:
1. all of the qt-related source files in svn lack correct eol style (namely native)
2. why does this use precompiled headers ? in my experience they were almost always a speed loss instead of gain during build ?

[Clements]

Installing the MSVC2008 runtimes (vcredist_x86.exe) works fine.

However, the latest vba_qt_dlls package [Post #64] does not without MSVC2008 runtimes installed. There must be some other dependency. I tried copying the various DLLs from the redist from the WinSxS folder, with no luck.

[Omegainf]

Still no love for linux?

[Spacy]

Originally Posted by Omegainf

Still no love for linux?

We love Linux - and Mac of course. We just don't use it (mudlord&me).
If you want to try this out, use svn to get the code and compile it using the
short how-to on https://vbam.bountysource.com/wiki
If you're on Linux you should be used to that for special/new software that's not in the repos.


@Clements:
I tried it out for myself and you're right. If the two runtimes sit in the WinSxS folder, everything's fine. But if I rename one of them so WIndows won't find it and copy it with the correct name to the VBA.exe folder, it doesn't find it.
Welcome to Windows DLL hell

I'll try to figure something out, because I want VBA to be portable.

Edit:
OK, I read up on that issue and I came to the conclusion, that the embedded manifest file in the exe (done by the dynamic configuration of Qt) tells Windows to look only in the WinSxS folder instead of the local folder. Writing application configuration manifest files (xml) is pain in the ass. Solution: Compile with mingw or compile static. I think I'll create release builds with mingw from now on and only use MSVC for myself.

[Dualscreenman]

Is there anything special I have to do if I want to redist Linux executables? I use Linux regularly.

[Spacy]

I updated to Qt 4.3.4 and compiled with MinGW.

The DLL package has been updated and contains the new Qt DLLs (official build 4.3.4) and the official mingw runtime DLL (15 KB )

The other link contains the vba-qt-build using mingw.

This time it should really work ^^"


http://vba-m.ngemu.com/vbam/vbaother...vba_qt_dlls.7z
http://vba-m.ngemu.com/vbam/vbaother...a_qt_svn385.7z

[Clements]

I can confirm that the newest build definitely works now without the MSVC2008 runtime package installed.

[Spacy]

Nice.
I set my build system up, so that I have the original mingw-compatible .a Qt-libs for release and msvc-compatible .lib libs for debug. I wouldn't have thought this would actually work without conflicts. I wrote a small cmd-line script to compile the release builds with a double-click on a desktop-icon, while I develop&debug with Visual C++ 2008 Express.

I can really recommend this combination for Windows Qt developers ^^


I just added ROM file selection, basic validation & loading code to the Qt build.



EDIT
I made changes to the rendering system.

It will now use either OpenGL or QPainter, depending on what is available.

The smart thing is that I can do everything with QPainter and Qt will translate it to OpenGL calls.


One issue in Qt is the timing. Even though I create a 60Hz timer, I only achieve about 40fps. But with idle time processing (timer interval 0) I get over 1000fps, so it should be possible to build something on top of that.


We'll also have to look into the Threading possibilities of our emulator.


Here's the binary for today: http://vba-m.ngemu.com/vbam/vbaother...a_qt_svn389.7z

[mudlord]

It will now use either OpenGL or QPainter, depending on what is available.
The smart thing is that I can do everything with QPainter and Qt will translate it to OpenGL calls.

Neato!

One issue in Qt is the timing. Even though I create a 60Hz timer, I only achieve about 40fps. But with idle time processing (timer interval 0) I get over 1000fps, so it should be possible to build something on top of that.

We'll also have to look into the Threading possibilities of our emulator.

Okay, have you looked into Boost::Threads by any chance? Qt also offers threading support too, which could be useful for dual core optimizations.

[Spacy]

I know Qt offers threads, but the question is, what exactly could be run as a seperate thread, as the data flow in VBA doesn't offer many possibilities.

In the MFC build it's like the following:

Emulate frame -> output frame (video/audio) -> Emulate frame...
The steps depend on each other. One way of optimizing would be to start emulating while the outputting the last frame.

Pixel filtering could also be thread-optimized by splitting an image into several areas and do filtering on them independently. Of course there has to be some overhead since you would see the borders in the image.

[Squall-Leonhart]

i think it would be useless to bother trying tbh.

if you want multithreading, try adding split screen linking support :P

[mudlord]

I know Qt offers threads, but the question is, what exactly could be run as a seperate thread, as the data flow in VBA doesn't offer many possibilities.

In the MFC build it's like the following:

Emulate frame -> output frame (video/audio) -> Emulate frame...
The steps depend on each other. One way of optimizing would be to start emulating while the outputting the last frame.

Pixel filtering could also be thread-optimized by splitting an image into several areas and do filtering on them independently. Of course there has to be some overhead since you would see the borders in the image.

I think its time we have a IRC meeting on this issue as it will ultimately effect all platforms we target. Plus, Nach might have some valuable input into this issue.

[Dualscreenman]

When you do have a meeting, I'd like to sit in on it. I think it'd be good to announce it so that those who want to watch/participate can do so.

[mudlord]

In that case, get on IRC. Now. We are also discussing linking as well, plus loads other related topics to the Qt4 build.

[MNK]

It's not Qt related, but as this is most active thread lately, I think it's time to...
be annoying again.
In latest svn (rev. 413) following thing should be fixed:
in agb/GBA.cpp: GBAGFX.h!=GBAGfx.h
in agb/GBAGfx.h: there's a `#include "gbaGfx.h"` line
in sdl/SDL.cpp: few of `#include` headers need to be updated to new locations

I think there's at least one more thing, but as I already fixed it and forgot, it was probably just as trivial. After those fixes, svn works correctly.

[Squall-Leonhart]

im not seeing GBAGfx.!
it says #include "GBAGfx.h"