Developer's wanted [Archive]

Spacy

August 24th, 2006, 20:06

Hi.
Since we currently do not have enough active developers, it would be great if YOU could help us out.

The requirements:
You are interested in how your good old GBA or GB worked.
You have C or C++ developing skills and or want to improve those.
You want to give something back to the community or you want your nickname to become well-known [believe me, it works ^^].

Well that should be almost everything you need. A copy of Windows and Visual C++ would be nice, if you want to help with the Windows part.

EDIT:
It would also be nice if there was someone who could take care of the Linux build system, since the bug reports state that GCC4 compatibility is not very good and the makefiles could also need little improvements.

If you are interested and more or less meet the requirements, talk to me per ICQ or pm me.

KingHanco

August 25th, 2006, 15:58

I post here at - http://www.mameworld.info/ubbthreads/showthreaded.php?Cat=&Number=84921&page=0&view=expanded&sb=5&o=&fpart=1&vc=1

You might get lucky. :)

Get them to know you and if you having any problems then just ask for help from them.

Forgotten

August 26th, 2006, 01:13

Also, try to get someone who is interested in optimizing the main core. That's where the attention should be. I think PokemonHacker did a great job with compatibility, but the speed is probably suffering a bit now.

KingHanco

August 28th, 2006, 00:30

Look like nobody care about doing the official vba anymore and move on to their life.

There is alot of fixes that need to be done. :(

Cooguy1212

August 28th, 2006, 00:54

Shoot I care

Shori

August 28th, 2006, 01:18

Theres always "Hope" guys, did u think that imposible for a ps2 to be emulate but as u can see there it is alive and kicking, in VBA case theres a high posibilities to be fix and to became the best gba emulator... all is need are time,developer and patient... :thumb: never give up :agree:

jchillin

September 22nd, 2006, 18:18

if i was a developer in anyway i would love to join in on this project...

a lot of people care but are just too stupid to help lol

Hatorijr

September 23rd, 2006, 22:06

umm i am actually pretty interested, i have a good knowledge of c and c++ and i have a bit of spare time handy since i really have no new projects i can work on(i just spend my spare time improving on what i already have done) how can i go about picking this up and working on it?

anderton

September 24th, 2006, 12:17

I would also be interested in helping. I have some programing, cpp knowledge and would help in any way i could. PM me with more details about how to become more involved in this please.

Forgotten

September 27th, 2006, 00:48

What I suggest people do is to send patches and fixes to problems. That's probably the best way of helping. The emulation core could certainly use some performance speed ups.

Shin_Gouki

September 27th, 2006, 17:52

this forums is more likly for emu "users" not for emu devs, try to post in some Linux forums u might be more lucky
@spacy :O na wie gehts alles klar? Ich hoffe alles io bei dir ;)
wbr Shin Gouki

Spacy

September 27th, 2006, 19:23

Nice, I already got 3 offers :D

As Forgotten said, the most helpful thing is to have a look at
https://sourceforge.net/tracker/?group_id=63889&atid=636220
and
https://sourceforge.net/tracker/?group_id=63889&atid=505529
and send to patches to
https://sourceforge.net/tracker/?group_id=63889&atid=505531

If you want to do even more, like for ex. adding new features or writing a new GUI from scratch, contact me and I will grant you developer access.

I personaly won't do very mutch on the code anymore, since I started to always be short of time since I reached the 12th class of school.
And on top, I switched to Linux (finally), so no VC++ 2005 anymore :D

But don't worry, I will still moderate this forum.

@Shin_Gouki
Hiho, meld' dich ruhig per ICQ doer MSN, wenn du willst ;)

zerbirus

November 7th, 2006, 08:16

i dont know any C++, but would be interested in trying out vba if you release anything, i have 2 machines with win98se and winxp sp2, one of those with a pentium 3 processor and one with a amd k6, 1 with 128mb of ram, the other with 256mb

i also downloaded all versions you released on the website :D

Yeah speed has rapidly decreased in the recent versions, v0.9a (which i use the most) is prety fast and works great, apart from the gundam seed rom with the faces, and a few that dont work on it, 1.72 is speedy and great compatibility, i use 1.72 if it doesnt work with 0.9a :D

mardy

November 18th, 2006, 08:41

I also could help a little with Linux development, but I have some concerns about the development process: it seems that most of the bugs and patches in sourceforge are actually being ignored. Even some major ones such as Andrew Church's armthumb patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1292942&group_id=63889&atid=505531) are still in the tracker with no comments from any VBA developer; I'm not saying that that patch must go in, but hey, please at least post a comment about it so people know if it's worth to spend time developing patches, or if anyway they will never get applied. :???:

SirdarBey

March 19th, 2007, 01:21

I am more than happy to work on the emu. I have and use VS on a regular basis, and have extensive programming experience. The first thing I want to do is keep it from dropping Vista out of Aero. Beyond that, I can work on bugfixes, etc.

Thanks, and PM me.

I personaly won't do very mutch on the code anymore, since I started to always be short of time since I reached the 12th class of school.
And on top, I switched to Linux (finally), so no VC++ 2005 anymore :D

I'm hoping this doesn't mean that you're breaking the build process on VS and creating some makefile project?

I also could help a little with Linux development, but I have some concerns about the development process: it seems that most of the bugs and patches in sourceforge are actually being ignored. Even some major ones such as Andrew Church's armthumb patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1292942&group_id=63889&atid=505531) are still in the tracker with no comments from any VBA developer; I'm not saying that that patch must go in, but hey, please at least post a comment about it so people know if it's worth to spend time developing patches, or if anyway they will never get applied. :???:

And yes, what does this mean for development?

SirdarBey

April 2nd, 2007, 00:23

hello? is this thread dead?

Smooth Criminal

April 2nd, 2007, 08:56

well any tester needed ??

denopqrihg

April 5th, 2007, 19:50

TheCloudOfSmoke

April 5th, 2007, 20:07

It seems that you're the only one left to maintain a build of the VBA. I hope that you or someone can incorporate all of the best improvements in all of the various builds into one. Anyways, good luck denopqrihg.

Foxfire Inferno

April 8th, 2007, 16:58

Hi guys!
Looks like I'll finally get some spare time (after a year or so).

I'd be happy to speed up the core, if nobody's against. Actually, I've begun doing this a year ago, but never finished, I've only rewritten some of the opcodes into assembler. Then I had a problem with compiler optimization and before I solved that, I had to drop the whole thing.

(I'll have to peek in at VBALink homepage, too :innocent:)

That would be excellent in terms of making the emulator even better than it already is, especially since I love VBALink.
The one thing that I wonder about though, is one of the main FAQ answers on VBA's Official Website:

2. Will link ever be supported?
For the time being, I've decided not to add link support. The reason is that link would increase the interest in the emulator by users using illegal copies of software.

Considering that, do you think the VBA Team still feels that way and that it'll still have an effect in the future possibility of adding a full Link support to VBA?

denopqrihg

April 11th, 2007, 20:56

I asked Forgotten some time ago, and he said he had no problem with it. But then again, before doing any considerable work on the integration, I had to leave.

I'll try to add it and see what happens ;)

Spacy

April 11th, 2007, 21:19

Originally Posted by VisualBoyAdvance Homepage (http://vba.ngemu.com/faq.shtml)
2. Will link ever be supported?
For the time being, I've decided not to add link support. The reason is that link would increase the interest in the emulator by users using illegal copies of software.

Sounds pretty weird, because I think people will also use "illegal copies of software" without link support. I don't see a connection between link support and illegal copies.

By the way, I tried to compile VBA with something else than VC++, but that's really a pain, because I do not want to use plain makefiles, but Eclipse or any other gcc/mingw-compliant IDE with code completion & syntax highlighting. Well, I guess I have those problems only because I still develop on windows, but unfortunately I am still a n00b in Linux-Buildsystems.

But I will continue to search for the optimal way of development :)

enderandrew

May 19th, 2007, 00:19

ODECiF

June 11th, 2007, 04:48

i would like to join the party too. I may do the translation part to swedish if it'll ever be necessary.

Squall-Leonhart

June 12th, 2007, 03:10

^^ and im always around to put the emu through the bug tests if needs be.

Exophase

June 12th, 2007, 04:03

Cooguy1212

June 12th, 2007, 04:17

Hey Exophase. I didnt know you spent time here?

Squall-Leonhart

June 12th, 2007, 04:37

Why don't you get serious and write a dynarec instead? Taking that code and converting it to assembler (in addition to what has already been written in ASM) will give you a grand benefit of almost nothing.

Also, VBA's renderer is extremely inefficient.

how do you figure that?

Cooguy1212

June 12th, 2007, 05:00

Trust me, He is very smart.

Squall-Leonhart

June 12th, 2007, 05:34

not really.

the problem isn't the renderer, its a lack of core optimisations.

Cooguy1212

June 12th, 2007, 05:37

You don't think hes smart?

Squall-Leonhart

June 12th, 2007, 05:43

not in this case.

the renderer is as efficient as D3D, OGL and DDraw allow it to be, the problem lies in the lack of optimisations in the GBA Core, causing slowdowns and the such.

Exophase

June 12th, 2007, 14:41

not in this case.

the renderer is as efficient as D3D, OGL and DDraw allow it to be, the problem lies in the lack of optimisations in the GBA Core, causing slowdowns and the such.

Sorry, but you don't know anything about it. The fact that it uses D3D/OGL/whatever only applies to the final blitting. The actual rendering of the GBA video is extremely inefficient. I know this for a fact because the renderer in my GBA emulator (gpSP) is several times faster.

Main reasons why it's so slow: composites each layer to a separate buffer, composites sprites to an entire layer, does Z-testing on each pixel against sprites, and possibly worst of all tests all 128 sprites for visibility every scanline. Also color space issues and color conversion and just lack of general optimizations bog it down further.

Squall-Leonhart

June 12th, 2007, 14:57

Exophase

June 12th, 2007, 15:33

no, i don't know much about the graphics, but going from discussions with spacey in the past, i do know that the Core does have lot of lack in optimisations, which would speed up emulation performance. such issues can be seen with how the emulator slows down while just walking around in a simple game like pokemon. (hell.. even FF2 didi t...)

It more likely slows down because of the aforementioned rendering issues than because of the "core" (I assume you refer to the CPU). Although VBA's DMA emulation could use some serious optimizations too. The CPU emulation is the most optimized part (rather brute force optimized) so I'd like to know why Spacey thinks that it has the most room for improvement. There are some tweaks that can be done to improve the interpretation speed, but unless a dynarec is employed then I doubt interpreter enhancements will make that big of a difference.

BUT!, this seperate layer business,.. would that account for why it ends up laggy when running on a Geforce 4 TI at 1280x1024, with triple buffering on?

I think I have to really clarify that the video card makes almost no difference here because the thing is being rendered in software...

lol, and seriously, if you can improve it, then you know how to contribute, if you have skill in the GBA emulation area, instead of condescending, how bout showing the guys where they can improve features instead of just telling them it'd work better a certain way. we get this same issue from the live beta teams not listening to us testers on major issues....

Isn't that what I'm doing? First and foremost I have to see if they're even interested in listening, I think most people who don't know who anything about me would disregard me immediately like you have.

Besides that, my emulator is open source, and it's not as if no one has ever heard of it. Granted, it's for handhelds which means that most people doing emulators on the PC won't really have noticed it (doesn't help that ngemu reports Daedalus and not gpSP, buhh) but they've seen its name so they can go find it.

And I welcome talking to anyone about this. Sometimes I even go after other devs (like the one currently working on PocketGBA) but not often.

At any rate, I'm obviously not going to be working on someone else's GBA emulator when I could be working on mine instead, so don't bother recommending that I do.

When you got down to it few people are going to care about optimizing VBA because almost all PCs are fast enough to handle it. So I'm not so much telling people to optimize it, I'm more asking why they'd waste their time on converting interpreter opcodes to ASM (more than they already have been)..

Squall-Leonhart

June 12th, 2007, 15:52

well.. i for starters didn't know about your emulator, as i don't have any interest in psp's, as nifty as they sound sometimes, so i did not have any clue about your skills.. i just went on the defense of VBA because you seemed to be attacking it in your first post.. which my tired brain probably misinterpreted... as usual :\

also, its not so much it would benefit VBA, but what if someone decides to branch off and start a VBDS emulator.. i dunno if that'd sit well with forgotten, but i would love to see a DS branch off,

although, i wish forgotten was still working on the project... the guy new what he was doing and the project seemed on track while he was onboard... with all the recent WIP's has managed to break multiple megaman Zero games, lol

it kinda sucks to have to choose between using 1.8 for compatibility, and 1.7 for speed :/

enderandrew

July 24th, 2007, 14:47

When you got down to it few people are going to care about optimizing VBA because almost all PCs are fast enough to handle it. So I'm not so much telling people to optimize it, I'm more asking why they'd waste their time on converting interpreter opcodes to ASM (more than they already have been)..

For one, optimized code will run better on other platforms besides the PC as well, not to mention not everyone has a blistering PC. I can't tell you how often I hear about VBA's inability to run full-speed on people's PCs.

The VBA code is available on SF's site. You can download it freely and do your best to improve it. There aren't many people working on the project anymore, but if you attempt to contact them directly I'm pretty sure someone will gladly give you SVN access. This very thread serves to state they are looking for developers to help.

It seems you have a clear plan to remove some redundancy in the rendering process. I'm not sure if you can also offshoot some of the load to the GPU, but it would be nice to see any improvement.

Exophase

July 24th, 2007, 15:51

For one, optimized code will run better on other platforms besides the PC as well, not to mention not everyone has a blistering PC. I can't tell you how often I hear about VBA's inability to run full-speed on people's PCs.

But I'm personally not at all interested in developing VBA. I have my own reasonably portable GBA emulator to develop, which has been filling the gap for other platforms (mainly handhelds). You can't really optimize VBA to be "fast enough" for those without rewriting a large portion of it.

The VBA code is available on SF's site. You can download it freely and do your best to improve it. There aren't many people working on the project anymore, but if you attempt to contact them directly I'm pretty sure someone will gladly give you SVN access. This very thread serves to state they are looking for developers to help.

There's already public CVS access with code that's much newer than what's on SF (which is actually quite out of date). Naturally I've had the source code for a long time or I wouldn't be criticizing it in the first place.

It seems you have a clear plan to remove some redundancy in the rendering process.

No, I was merely comparing its rendering process to a more suitable one. What you're suggesting would require a total rewrite of VBA's renderer which of course I'm not going to do.

I'm not sure if you can also offshoot some of the load to the GPU, but it would be nice to see any improvement.

Sorry, but I never said anything about moving things to GPU :P

Hard core Rikki

July 24th, 2007, 16:45

I was merely comparing its rendering process to a more suitable one. What you're suggesting would require a total rewrite of VBA's renderer which of course I'm not going to do.

Sorry, but I never said anything about moving things to GPU :P

How about just using dirty rectanglin or a VMEM to VMEM strechblittin, then ? Stretchblitin shoul work way faster for most (old x86 comps especially), without breaking anything (maybe a few transparency-related graphic quirksthough, like visual fx and sprites. should be fixable by making vba blit twice)

plaes

October 26th, 2007, 14:52

Is there any work being done on VBA?

Could you please at least move from CVS to SVN and apply their latest patches... ;)

Hard core Rikki

October 26th, 2007, 15:19

Is there any work being done on VBA?

Could you please at least move from CVS to SVN and apply their latest patches... ;)

Pretty much, there is NO MORE activity on the official VBA. A shame.
With the author Forgotten out of the picture, noone stepped in to continue work on it (except VBA Team basically, but that didnt last too much either apparently).

What would be needed now, is to RETROFIT the new stuff and fixes that originated in the forks, into the *official* VBA, for everyone's benefit.

daytonausa2020

October 27th, 2007, 23:16

I could help, I am making currently a dreamcast emulator (which now has the ability to load the bios very slowly), but I need sound support later on, because I learned ARM architexture.... and the sound runs off an ARM7, which is the same core as the iPod and GBA :P

;) So I could help you with your project and possibly get help with mine... :bow:

shashClp

October 27th, 2007, 23:35

What would be needed now, is to RETROFIT the new stuff and fixes that originated in the forks, into the *official* VBA, for everyone's benefit.

Aren't all those forks difficult to find? Because it's not like merging different forks of a versioned source code base is rocket science. I guess if someone did a list of the fixes on different code bases, with their source code, merging wouldn't be that much of a problem. But it's a rough guess, depends on the ammount of changes, of course...

Hard core Rikki

October 28th, 2007, 10:06

Aren't all those forks difficult to find? Because it's not like merging different forks of a versioned source code base is rocket science. I guess if someone did a list of the fixes on different code bases, with their source code, merging wouldn't be that much of a problem. But it's a rough guess, depends on the ammount of changes, of course...

To find ???
Well, checking the known ones like vbalink and ones listed in spacy's list (http://forums.ngemu.com/visualboy-advance-discussion/71320-visualboyadvance-link-collection.html) should be nice for starters, unless the 1.8.0 core needs more attention before retrofitting is worth attempting?
For forks built on the 1.7 codebase, couldnt their fixes/improvements be adapted to 1.8 without too much hassle ?

mudlord

October 28th, 2007, 11:31

MasterPhW

October 28th, 2007, 12:51

Hmm, this is actually something I might look into.

Since recently I have been having a strange & very strong programming appetite and can't suppress it no matter how hard I try, I might do this. Depends on the compiler used, but I'll see what I can arrange.

I know kode54 (one of the HydrogenAudio admins) made a very nice VBA build with LCD emulation, and some very nice audio patches using blargg's sound library.
Yeah, mudlord, you seems to be one of the most active devs in the emulation community with some of the greatest projects, really.
I like all the things you are doing and looking forward to the Rice build with pixel shader support atm.
But I would also like to see a ALL-IN-ONE VBA version. That would rock!
IMHO the version of Spacy had the best version of a new menu sheme, would be great to have that back! And the fixes of these other forks would really enhance the GBA experience!

mudlord

October 28th, 2007, 14:12

Yeah, mudlord, you seems to be one of the most active devs in the emulation community with some of the greatest projects, really.

^_^

I like all the things you are doing and looking forward to the Rice build with pixel shader support atm.

I know lots of people have been wanting proper cel shading for some time, ever since Orkin had discovered a way to do accurate cel shading through improvements based on his per pixel lighting code in Direct64. I thought bout time that everyone could use shaders with thier games. As you might have seen, I have already released some public tools used to help author the shaders, which leaves then I guess to finalise the shader support and add it in the public DX9 build. All in all, I am very pleased with my work on the plugin thus far, and I'm happy everyone is too. I know some texture artists were super pleased with the 8x/16x support and I'm starting to see like a renaissance in retexing, as well as now another video plugin starting to support Rice Video format textures...

But I would also like to see a ALL-IN-ONE VBA version. That would rock!
IMHO the version of Spacy had the best version of a new menu sheme, would be great to have that back! And the fixes of these other forks would really enhance the GBA experience!

So basically, what patches and forks you want combined?

EDIT: I checked out the main 1.7.2 source. It seems compiler usage won't be a problem, since it uses plain MSVC6 as well as the newer MSVC compiler sets.

MasterPhW

October 28th, 2007, 14:22

MMh...
The fixes and tweaks in Kode54's VBA build, the Hacking features of VBA-H, the recording features of VBA Rerecording, the Link features of VBALink and VBALinkReal, the VBA smooth Plugin compatibility and the menu and specials of VBA-S.
But it's much harder than it seems! :)
But I wish you good luck with all your projects, keep them going.
Btw: I also support you besides with the collection of all texture packs on ET! :)

mudlord

October 28th, 2007, 14:26

Indeed, its much harder than it sounds, as I will need to check up on each one and see what codebases there are on. I'll add each forks features incrementally and see how that goes.

EDIT: Well, it seems Spacy's build is on 1.8.0 beta, and kode54's patch is on 1.8.0, so it looks portage to 1.8.0 needs to happen it seems...Just need to find the 1.8 beta's original source code...

TheCloudOfSmoke

October 28th, 2007, 15:13

Yeah, mudlord, you seems to be one of the most active devs in the emulation community with some of the greatest projects, really.
I like all the things you are doing and looking forward to the Rice build with pixel shader support atm.
But I would also like to see a ALL-IN-ONE VBA version. That would rock!
IMHO the version of Spacy had the best version of a new menu sheme, would be great to have that back! And the fixes of these other forks would really enhance the GBA experience!

I agree. I hope that someone can at least put in all of the builds together. That would be great. Much respect to anyone who takes on the project. :) Although, I do like Spacy's build, I don't like the arrangement of things. I prefer the original VBA layout without any features taken out. It's not good to downgrade by taking away seemingly useless features because some people actually use certain features.

mudlord

October 28th, 2007, 15:41

Although, I do like Spacy's build, I don't like the arrangement of things. I prefer the original VBA layout without any features taken out. It's not good to downgrade by taking away seemingly useless features because some people actually use certain features.

Hmmm, well has any one got the link to the 1.8.0 beta source code? I can't seem to find a link to a package with it. I'm just going to redo the patches based on the clean 1.8.0 source, that is, if I can find it first.

Also, I am having difficulties obtaining the latest VBAsmooth source. The homepage seems to be down and archive.org doesnt seem to want to co-operate with me too well :(

shashClp

October 28th, 2007, 16:04

To find ???

Well, just check this...

Hmmm, well has any one got the link to the 1.8.0 beta source code? I can't seem to find a link to a package with it. I'm just going to redo the patches based on the clean 1.8.0 source, that is, if I can find it first.

Also, I am having difficulties obtaining the latest VBAsmooth source. The homepage seems to be down and archive.org doesnt seem to want to co-operate with me too well

Do you see what I was talking about? :)

MasterPhW

October 28th, 2007, 16:24

Here are all the sources I've found and uploaded these files:

--------------FULL project sources!-----------------
VBA-Spacy WIP 2006 02 11 SRC (http://rapidshare.com/files/65834839/VBA-S_WIP_2006_02_11_SRC.7z)
VBA-Spacy WIP 2006 04 14 src (http://rapidshare.com/files/65834861/VBA-S_WIP_2006_04_14_src.rar)
VBA-Spacy 1.76 Source (http://rapidshare.com/files/66108030/VBA_S176_SRC.7z)
VBA CVS 2005-10-21 (Kode54's Build) (http://rapidshare.com/files/65834508/VBA_CVS_2005-10-21__Kode54_.7z)
VisualBoyAdvance-H LS0.20 (http://rapidshare.com/files/65835104/VisualBoyAdvance-LS0.20.rar)
VBA Rerecording Build19-src (http://rapidshare.com/files/65841804/vba-rerecording-19-src.7z)
VBA Rerecording Build20-src (http://rapidshare.com/files/65841834/vba-rerecording-20-src.7z)
VisualBoyAdvanceED 1.4 src (http://rapidshare.com/files/66357809/VisualBoyAdvanceED-1.4-src.zip)
--------------Patch Files collected so far------------
k54's patches (http://rapidshare.com/files/65834915/visualboyadvance-1.8.0-k54.patch.bz2.zip)
1.73 Link Patches (http://rapidshare.com/files/65834780/vbalink173src.tar.gz.zip)
hq3x speed and vidion patches based on VBA-S 1.76 (http://rapidshare.com/files/66108222/VBA-djrobx-hq3xasm-VBAS176-SrcUpdate.zip)

mudlord

October 28th, 2007, 16:39

Thanks for the sources to VBA-S, and VBA-H...

All I need now is VBAsmooth sources and the 1.8.0 beta code...

MasterPhW

October 28th, 2007, 16:58

But as I said, I don't know, if that are the most up to date sources!
But they are the only ones I still have on my HDD.
But I will continue to research!

mudlord

October 29th, 2007, 03:19

Thanks for the sources.

So far I managed to compile VBA-S.

Since that seems to be based on 1.8.0 beta, I might have to use that as a base, and plus, VBA-S compiles clean straight out of the box, which helps simplify things, whereas the official 1.7.2 build completely trips on GBA.cpp and crashes the compiler (I'm using MSVC2003)..

djrobx

October 29th, 2007, 19:42

I've been poking around the various VisualBoy sources because none of them worked quite right on my Vista boxes, and I wanted HQ3X at 60hz with vsync.

I have something I want to contribute - I have fixed a bug and added an offset feature to the HQ3X assembly-optimized sources to allow it to work with VisualBoy. MaxSt's source has a bug where it forgets to increment the destination pixels a bit when "pitch" is less than Xres * Pixelsize. I also added an Offset to accommodate source image pitch. I see VBAS and others are using the C-based HQ3X which is much slower.

Now, onto my experiences with the various versions:

The DirectDraw capable builds seem to work best with Vista, *but* most of them lack the ability to specify 60hz refresh rate. Vista's dxdiag no longer has the option to lock refresh rates, and many drivers ignore manual monitor selection (e.g. they will pick 75hz if your monitor is capable if you leave refresh rate blank in the DirectDraw create call, which is what existing sources do). "VBA Smooth" works well except for this issue. Unfortunately the VBA Smooth sources do not appear to be available anywhere!

Spacey's Direct3D only builds will not vsync on any of my Vista boxes (NVidia, Intel GMA) nor my Windows XP box with ATI Radeon, no matter what I do. Not sure why (it's using the correct D3DPRESENT_INTERVAL_ONE), but no matter what combinations of settings I try I get ugly tearing.

I found an older version of VBAS source (from the main download area of this site) that still has the DirectDraw code in it and was able to get the assembly optimized HQ3X into it. It works well. But I'm not even sure how old underlying VisualBoy source is or what improvements have been made to it since then.

For now I have only fixed the 16 bit hq3x assembly implementation. I can also work on the 2x and 4x and 32 bit versions, but I would want to do so against current sources that are actively being developed. I checked out the CVS version from SourceForge but it doesn't seem to include anything but hq2x and I can't really tell how "new" it is.

My concern with you using the more recent VBAS as a base is that the DirectDraw code has been removed. I guess we could re-integrate it if need be.

The kode54 build source posted here does not include all of his sound updates (per the links thread). VisualBoy would really benefit from sound interpolation. If we cannot track his source down I can add that too. So we still would benefit from recet sources for Kode54 (sound) and VBA-Smooth (use Kega video plugins). It's a shame so much source seems to have been lost. We gotta get a CVS or SVN going!

MasterPhW

October 29th, 2007, 21:05

djrobx

October 29th, 2007, 21:36

Sure.

I found VBAS 1.7.6 here

The Emulation64 Network - NextGen and Retro Emulation News and Support (http://www.emulation64.com/files/info/647/VBA/)

And here is an archive of the files I modified to the above archive for HQ3X assembly and 60hz setting. You can just extract over the VBAS 1.7.6 sources if you want to try it. There's a bunch of other files (lq3x, lq4x, etc) that aren't functioning yet. I use Visual Studio 2005 and nasmw to compile.

http://www.djrobx.com/misc/VBA-djrobx-hq3xasm-VBAS17-SrcUpdate.zip

MasterPhW

October 29th, 2007, 22:50

I think this thread is the most complete source collection of VBA at the moment!
I also uploaded them all to rapidshare, to keep the links and the sources alive, this time!

Hard core Rikki

October 29th, 2007, 22:52

I think this thread is the most complete source collection of VBA at the moment!
I also uploaded them all to rapidshare, to keep the links and the sources alive, this time!

dupe-saving that to HDD and an ftp would be nicer. rapidshare not really a superreliable file hoster after all.

mudlord

October 29th, 2007, 23:28

I have started a project homepage here:
https://vbam.bountysource.com/

Also, with BountySource, we get a working Subversion server which is at:
https://svn.bountysource.com/vbam/

I found it a reliable project site for my Rice Video work.

Unfortunately the VBA Smooth sources do not appear to be available anywhere!

I know...I have hunted everywhere for them, alas I've been unable to turn up nothing :( Hi there, btw, aren't you the same djrobx that made those cool filters for MEKA?

I found an older version of VBAS source (from the main download area of this site) that still has the DirectDraw code in it and was able to get the assembly optimized HQ3X into it. It works well. But I'm not even sure how old underlying VisualBoy source is or what improvements have been made to it since then.

Same here, its new territory for me too.

The kode54 build source posted here does not include all of his sound updates (per the links thread). VisualBoy would really benefit from sound interpolation. If we cannot track his source down I can add that too. So we still would benefit from recet sources for Kode54 (sound) and VBA-Smooth (use Kega video plugins). It's a shame so much source seems to have been lost. We gotta get a CVS or SVN going!

Well, it use blargg's sound libs for audio emulation, which is easy to get otherwise. The resampling code is libresample or smth like that IIRC. Yeah, it is a big shame that mose VBA sources have gone by the wayside, which really sucks. And I set up a SVN server. :)

MasterPhW

October 29th, 2007, 23:57

dupe-saving that to HDD and an ftp would be nicer. rapidshare not really a superreliable file hoster after all.
Yeah, I know, but it's better than nothing and I have a premium account, so that mean that the mirrors will live longer and will be available for a while!
And they are now also stored on my HDD! :)
I have started a project homepage here:
https://vbam.bountysource.com/
Also, with BountySource, we get a working Subversion server which is at:
https://svn.bountysource.com/vbam/
I found it a reliable project site for my Rice Video work.
I know...I have hunted everywhere for them, alas I've been unable to turn up nothing :( Hi there, btw, aren't you the same djrobx that made those cool filters for MEKA?
Well, it use blargg's sound libs for audio emulation, which is easy to get otherwise. The resampling code is libresample or smth like that IIRC. Yeah, it is a big shame that mose VBA sources have gone by the wayside, which really sucks. And I set up a SVN server. :)
Nice to see, that the project started that fast! Can't wait to see the first progress and the first release!
I really like you work and appreciate what you did in the last few month for the emu community! So, thanks for your great work and keep it up!
Hope all these sources helped you a lil bit!

djrobx

October 30th, 2007, 01:22

I know...I have hunted everywhere for them, alas I've been unable to turn up nothing Hi there, btw, aren't you the same djrobx that made those cool filters for MEKA?Hi. Yep, that's me. :)

Sounds good, I've joined your "community", if you can make me a developer that would be great.

It appears all K54's updated sound code is in the K54 patch that MasterPhW found. I'm working on integrating it into my VBAS1.7.4 tree. Because my source doesn't match whatever it was originally patched against it's taking a little extra work. I have a feeling I'm going to end up redoing this against whatever you submit to SVN as a base anyway. :)

mudlord

October 30th, 2007, 01:30

Hi. Yep, that's me.

Cool. I remember reading the changelogs for the new MEKA and your name popped up in it with regards to the HQ?? filters.

Sounds good, I've joined your "community", if you can make me a developer that would be great.

Done and done.

It appears all K54's updated sound code is in the K54 patch that MasterPhW found. I'm working on integrating it into my VBAS1.7.4 tree. Because my source doesn't match whatever it was originally patched against it's taking a little extra work. I have a feeling I'm going to end up redoing this against whatever you submit to SVN as a base anyway.

Ah okay, koolness

Nice to see, that the project started that fast!

Well, I try to be efficient :) Often when I'm in the mood to do something, I am really focused towards it, and motivated towards it as well. Its a common trait among Asperger's Syndrome affected people.

Can't wait to see the first progress and the first release!

:)

I'm glad that people are supportive. Makes me quite happy to do what I do.

I really like you work and appreciate what you did in the last few month for the emu community! So, thanks for your great work and keep it up!
Hope all these sources helped you a lil bit!

And thank you for the very kind words and support! These sources will certainly come in handy in the days and weeks ahead. My first work of order is to write some decent documentation. I honestly can't stand open source projects having bad documentation, so I'm gonna write a manual of sorts, like I do for my Rice Video builds. Plus, it keeps all the docs in one spot, as well as making it much easier to read.

djrobx

October 30th, 2007, 07:12

I have successfully applied the Kode54's patches against Spacy's 1.7.4 build. So now I have spacykode. :) It seems to work well, but it took a while to go through all the patch .rej files to get all the pieces working. The various sound filters definitely work so that is a plus. I also have assembler hq3x working in 32 bit mode although I found MaxSt's "hq3x32" assembly code wants to take 16 bit source and output scaled 32bit. So, I had to add some hacks to make the "system" resolution 16 bit while the filter outputs 32 to the display.

I am still working out some issue with GBC sound and libresample's output sounding grainy (compared to the downloadable Kode54 build). The other filters seem to work properly.

mudlord

October 30th, 2007, 09:11

I have successfully applied the Kode54's patches against Spacy's 1.7.4 build. So now I have spacykode.

Thats definately kool :)
That leaves us with VBA-H, VBALink, and the rerecording builds.

I also have assembler hq3x working in 32 bit mode although I found MaxSt's "hq3x32" assembly code wants to take 16 bit source and output scaled 32bit. So, I had to add some hacks to make the "system" resolution 16 bit while the filter outputs 32 to the display.

Oh alright. :) Its nice you got it working though.

I am still working out some issue with GBC sound and libresample's output sounding grainy (compared to the downloadable Kode54 build).

Oh okay. Just wondering, using Blargg's latest GBC sound emulator by any chance?

I have started to port over VBALink to Spacy's 1.7.6 build. It seems this build was the last before Spacy yanked out DirectDraw and OGL support...

djrobx

October 30th, 2007, 09:57

Ok, I worked the remaining issues out. The GBC roms and the libresample filter both sound correct now.

Here is my latest source (complete this time)

http://www.djrobx.com/misc/vba-djrobx-spacey-174-kode54-180.zip

I have started to port over VBALink to Spacy's 1.7.6 buildI'm glad to hear you've decided to base off the same source I did. That will make merging our efforts far far easier. :)

Squall-Leonhart

October 30th, 2007, 10:11

ok,
the VBA-S based on 1.8 is actually the older one, Spacy's later VBA-S builds were based on 1.7

Spacey's Direct3D only builds will not vsync on any of my Vista boxes (NVidia, Intel GMA) nor my Windows XP box with ATI Radeon, no matter what I do. Not sure why (it's using the correct D3DPRESENT_INTERVAL_ONE), but no matter what combinations of settings I try I get ugly tearing.Spacys builds lacked opengl (this sucked as it lacked Triplebuffering in Direct3D as well, which meant you had that nice tiling effect at the top of the screen), thankfully, mudlord, you know Opengl, so you won't remove it i hope :P for those who prefer to use Direct3D, it would help if you added an option for D3D Triplebuffering, as unlike Opengl, Direct3D has to request triplebuffering, where as Opengl it can be set globally.

the tiling actually happens in all 2D surface emulators, Jnes, Snes9x, VBA, and with all of them Vsync doesn't fix it, but Triplebuffering does.

it did have that nice setup dialogue, but it didn't actually work properly. not to mention that enabling something in the newer versions would disable it in the older versions.

the newest 1.8.0 version
(VisualBoyAdvance1.8 wip_2006_07_31)
has issues with Megaman games, where as the earlier build

(VisualBoyAdvance1.8 wip_2006_06_20)
did not have such issues.

Mudlord, i don't know about using spacys versions, specifically because he removed support for the vba-over file if i remember correctly.

mudlord

October 30th, 2007, 11:37

I'm glad to hear you've decided to base off the same source I did. That will make merging our efforts far far easier.

Yeah, definately, and on a related note, I have almost finished the implementation of VBALink into the current Spacy+kode54 source (just some final work on adding the extra GUI bits for the linking needs to happen, all linking related classes are added and it compiles fine, save for the missing GUI parts). Most likely after this, I will commit it to SVN.

ok,
the VBA-S based on 1.8 is actually the older one, Spacy's later VBA-S builds were based on 1.7

Ah okay, thanks for the info :)

Spacys builds lacked opengl (this sucked as it lacked Triplebuffering in Direct3D as well, which meant you had that nice tiling effect at the top of the screen), thankfully, mudlord, you know Opengl, so you won't remove it i hope :P

Course not, the OGL renderer will stay. :)

Squall-Leonhart

October 30th, 2007, 12:00

what VBA-Link version are you using btw? the 1.73-L or the 1.8-L version?
the 1.8l version supports wireless as well as normal linking where as the 1.73 version didn't :(

i would kill for VBA to be able to link GB/GBC games, that would totally kick ass!

mudlord

October 30th, 2007, 12:16

VBALink 1.73

dupe-saving that to HDD and an ftp would be nicer. rapidshare not really a superreliable file hoster after all.

I got lots of space free on my own personal homepage, which should do for the time being....

Squall-Leonhart

October 30th, 2007, 12:44

hmm that has basic support for wifi, it seems to work, has more options then the 1.8L version as well :P

mudlord

October 30th, 2007, 12:49

Ah okay.
At least the patch has now being added.

That leaves possibly VBA-H and the rerecording support then....

Squall-Leonhart

October 30th, 2007, 12:52

hmm, the 1.8 wifi code supports 4 players in wifi mode :\.. hmm need to obtain the 1.8l source... but can't find it anywhere >.<

mudlord

October 30th, 2007, 13:09

Thats precisely our issue. Code fragmentation and broken links everywhere :(.

Squall-Leonhart

October 30th, 2007, 13:34

it doesn't look like it was ever even released.

im looking for BGB or TGB source code, either may help add GB/GBC linking to VBA

heh, bingo

http://gigo.retrogames.com/tgb/tgb_dual_8_3_src.zip

maybe the linking method used in that can be ported to work in VBA :P

djrobx

October 30th, 2007, 17:47

this sucked as it lacked Triplebuffering in Direct3D as well, which meant you had that nice tiling effect at the top of the screenThank you for confirming that I'm not the only one with that issue. There is code for D3D Triple Buffering, it just doesn't seem to change the output much (it still tears). I can even force vsync in the driver and it makes no difference. Triple Buffering is currently working well in the DirectDraw rendering mode which is what I use currently. I haven't tested OpenGL yet. I assure you that the various render methods are here to stay in this new build. I am a stickler for vsync quality. :)
I have almost finished the implementation of VBALink into the current Spacy+kode54 source (just some final work on adding the extra GUI bits for the linking needs to happen, all linking related classes are added and it compiles fine, save for the missing GUI parts). Most likely after this, I will commit it to SVN.Perfect. I think I'm going to work on adding asm-optimized HQ4X and re-add LQ2X-LQ4X next. The Spacy 1.8 build has those bits that are not there in the 1.7 build. That should be easy for me to commit to SVN once you post it.

That leaves possibly VBA-H and the rerecording support then....Where is the VBA-H source and what features does it offer? Looking over the official SF.net CVS commit logs, it appears some of this code was already merged by pokemonhacker. Once we get our SVN I will go through pokemonhacker's updates and ensure we have them in our new codebase.

MasterPhW

October 30th, 2007, 19:58

Thank you for confirming that I'm not the only one with that issue. There is code for D3D Triple Buffering, it just doesn't seem to change the output much (it still tears). I can even force vsync in the driver and it makes no difference. Triple Buffering is currently working well in the DirectDraw rendering mode which is what I use currently. I haven't tested OpenGL yet. I assure you that the various render methods are here to stay in this new build. I am a stickler for vsync quality. :)
Perfect. I think I'm going to work on adding asm-optimized HQ4X and re-add LQ2X-LQ4X next. The Spacy 1.8 build has those bits that are not there in the 1.7 build. That should be easy for me to commit to SVN once you post it.

Where is the VBA-H source and what features does it offer? Looking over the official SF.net CVS commit logs, it appears some of this code was already merged by pokemonhacker. Once we get our SVN I will go through pokemonhacker's updates and ensure we have them in our new codebase.
This is the VBA-H source I've found. (http://rapidshare.com/files/65835104/VisualBoyAdvance-LS0.20.rar) It adds some hacking features, but don't know exactly. Sorry for the crazy name of the archive, but that was the name I obtained the source!
VBALink 1.80 never had a source release afaik, because it was ust a messy beta and they wanted to clean the source before releasing it. So another source and features was lost... sad.
BTW: atm I am writing a little help file in the style of the Rice Video help file of mudlord, to support the work of you both!
BTW: is it already possible to request a feature? I would like to get INI translation, I've wrote sometimes ago also a translation INI and wanted to add it myself to the code, but forget about it! O.o
Probably I can find it, to give an idea!

mudlord

October 30th, 2007, 20:06

I have committed the VBALink updates to the VBA build in SVN.

The updates have been completely untested though.

BTW: atm I am writing a little help file in the style of the Rice Video help file of mudlord, to support the work of you both!

That is super cool. :) I can't wait to see the finished product!

BTW: is it already possible to request a feature? I would like to get INI translation, I've wrote sometimes ago also a translation INI and wanted to add it myself to the code, but forget about it! O.o
Probably I can find it, to give an idea!

I'm not too sure about what you mean. Is it like a translation file of sorts?

djrobx

October 30th, 2007, 20:53

I have HQ4X assembler working. It works *very* well, I get 100% sync'd FPS on my Pentium D (dual 2.8ghz). I could barely pull off HQ3x with VBA-Smooth on this box.

I will check out your SVN and commit to it.

BTW: atm I am writing a little help file in the style of the Rice Video help file of mudlord, to support the work of you both!Your work in collecting sources has been very helpful and is much appreciated. Do you mean an .INI to translate the UI elements? That should be fairly easy to do since the VBA code was written using resource strings rather than hardcoded strings.

MasterPhW

October 30th, 2007, 21:44

Do you mean an .INI to translate the UI elements? That should be fairly easy to do since the VBA code was written using resource strings rather than hardcoded strings.
Yeah, a translation trough INI entries and INI translation, not through DLL translations like it's done with the official and all other builds, because with every new release, I had to recreate the DLL to have all the new options translated, with an INI it should possible to just add the new entries easier and faster!
Btw: found a new source of a Rom Translation VBA, called VBAEd... probably the source is also handy to have!
Here's the link, also added it to my main post (http://rapidshare.com/files/66357809/VisualBoyAdvanceED-1.4-src.zip)

djrobx

October 31st, 2007, 01:26

mudlord,

I have committed my HQ4X changes to the SVN. The "linking" code was crashing in Link.cpp due to linkmem being null. I added a comment and a check for NULL which allows the program to run, but you might want to check the source you merged from to find where linkmem is supposed to be initialized.

I have also updated the project files with some trivial other fixes so the project compiles in debug mode successfully.

Yeah, a translation trough INI entries and INI translation, not through DLL translations like it's done with the official and all other builds, because with every new release, I had to recreate the DLL to have all the new options translated, with an INI it should possible to just add the new entries easier and faster!I agree INI is the way to go. Although DLL has an advantage in allowing dialog customization, people shouldn't need to learn to build DLLs just to translate text!

mudlord

October 31st, 2007, 01:52

Thanks for the tip, I'll check it out. :)

EDIT: Looked through the VBALink patch. Seems that all references to the pointer linkmem (of the struct LINKDATA) are just in plain ol' Link.cpp. First occurance of linkmem is in StartLink(), though it doesnt seem to be explicitly initialised anywhere tho in the original VBALink sources..

Squall-Leonhart

October 31st, 2007, 11:50

Thank you for confirming that I'm not the only one with that issue. There is code for D3D Triple Buffering, it just doesn't seem to change the output much (it still tears). I can even force vsync in the driver and it makes no difference.

thats because its not a vsync issue :P, vsync locks the frame rate to the monitors refresh rate, but the emulators when running at 100% usually lock to either 60hz (60fps) or 50hz (50fps) the only exception is N64 which has a variable FPS (20-60fps or 18-50fps). the tiling/tearing occurs due to the difference in how the console outputs compared to a pc.

by default, most drivers default to double buffering, this is where the problem comes in, consoles of these types don't have a display buffer as such, and are rendered straight to screen, the default double buffering causes visual artifacts., by enabling triplebuffering, the third buffer somehow corrects the graphics and the tearing is removed.

the reason the opengl mode doesn't have tearing is that opengl uses the Triplebuffering mode set in the drivers options, where as Direct3D requires triplebuffering be requested, the emulator does not have an option to enable/disable Triplebuffering for D3D, so it can't be enabled., i have 100% faith that mudlord will be able to fix it, given the chance, considering his work in both D3D and OGL.

djrobx

October 31st, 2007, 18:57

I do understand how refresh rates and vsync are supposed to work. The driver is correctly selecting 60hz (and I also added a fix for the DirectDraw mode so you can speciify 60hz as well, actually that was the reason I got involved in this in the first place ... the current builds left me absolutely no way to set 60hz in Vista without using special refresh rate locking software).

"VSync" in most emulators means that an emulator will prepare its frame. It will then get to the point of refreshing the screen, and then do nothing until the display card gets to the Vblank area. This will create horrible performance if the computer can't quite keep up with the framerate, or the sync rate doesn't match the desired output (eg monitor is at 75hz but you are emulating a 60fps system).

"Triple buffering" typically means that there are three buffers, two for the display hardware, and a third that the software application can work on. The display hardware will automatically flip between the two back buffers when it's the appropriate time.

If VSync or triple buffering is on, the display should never tear, period. In either of those modes, the frame display is only to be refreshed at vsync. If the refresh rate of the emulator and display don't match, you should get a display that's jumpy, but not tearing. If tearing is happening with vsync mode ... it's just not working. If tearing is happening with triple buffer mode, then the application must be writing to one of the front buffers.

Squall-Leonhart

October 31st, 2007, 19:14

its not that its writing to the front buffers, atleast i don't think it is, but more the fact that the code isn't 100% for D3D Triplebuffering
there is some code in their for it, but theres no option to enable it, going from a convo i had with spacy in pm, the basics are there, but its not 100% complete.
the DDraw triplebuffering doesn't effect D3D triplebuffering, i did read some notes showing the different methods on calling for TB in both Ddraw and D3d once,.. just have to find them again.

i actually, don't have Vsync enabled in the emulator, just triplebuffering in the NVCP and for DDraw and the changes are obvious, thats why i think the tearing isn't exactly a vsync issue.

Triple Buffer - Tutorial - Introduction to Direct3D (http://triplebuffer.devmaster.net/file.php?id=7&page=7)
d3dpp.BackBufferCount = 1; = double buffering
d3dpp.BackBufferCount = 2; = triple buffering
thats how DxTweaker works anyway :\

looking at the VBA source, the only thing vba needs is a menu item and related coding to allow the emulator to use TB

djrobx

October 31st, 2007, 20:13

*Edit*

Okay, I figured out the problem. The issue is the backbuffer was being created with D3DPRESENTFLAG_LOCKABLE_BACKBUFFER being set. Removing that corrects the issue for vsync mode completely. I don't see anywhere in the code where the backbuffer actually gets locked (just the texture, as you would expect), perhaps it was a remnant of an early version of the code or something. Regardless, it's fixed.

I will look into adding the triple buffering mode present in the newer Spacy code. I suspect that lockable backbuffer setting also broke its ability to sync as well.

Squall-Leonhart

October 31st, 2007, 20:23

ah ok, so now it takes on the DDraw TB setting right? will have to rename that and move it

also, will save type > enhanced detection, ever be made to work :\

djrobx

October 31st, 2007, 21:22

According to Microsoft's documentation about lockable backbuffers, the impact of its use varies depending on the hardware used. I'm guessing it worked OK on Spacy's hardware, but disables hardware synchronization (regardless of buffering method) on yours and mine.

The 1.7.6 Spacy version that we are working off of has no triple buffer code in Direct3D. We do have the code you refer to, it's in the newer beta (the one where he removed the OpenGL and DirectDraw code). So we can merge it back in but it's not there at the moment. VSync option now works very well though. I think you'll be happy with it. I need to fix a small issue (see below), once I do I will post a compiled copy for you to test with and then you can tell me if it improves the situation for you.

Disabling lockable buffers has introduced a glitch with the menus (you can't see them, probably because the hardware acceleration is actualy working and the DX display seems to sit infront of the bar). The menus have blackout problems even on the official builds.

I'm going to try and work out a more reliable way to display the menus. Then I will post a build that you can test out.

also, will save type > enhanced detection, ever be made to work :\Personally I'm focusing on UI / Graphics / Sound issues right now.

Squall-Leonhart

October 31st, 2007, 21:54

the Triplebuffering code was also in the original 1.72 source, but it doesn't work in 1.72 either, and i can't find D3DPRESENTFLAG_LOCKABLE_BACKBUFFER in there

the issue you speak of, with the menus, also occurs to an extent in Snes9x though it was more a flickering of the menu

mudlord

November 1st, 2007, 00:19

Anywayz, I have started the task of implementing the functionality of nitsuja's re-recording support to our VBA build. I might look into adding VBA-H at the same time too..I'll also upload all VBA modifications I can find, as posted by MasterPhW, to my personal homepage (I might mirror them on my university personal homepage too, as I got unlimited bandwidth there).

Personally I'm focusing on UI / Graphics / Sound issues right now.

Ah okay, any issues in particular? Other than the Vsync problems?

djrobx

November 1st, 2007, 01:18

I'm happy with the D3D vsync performance now. It's the menu bar I want to clean up. I'm also part way into adding multiple key assignments to controller buttons (e.g. joystick UP OR joystick-hat UP OR arrow-up) instead of the current one-key limitation.

D3DPRESENTFLAG_LOCKABLE_BACKBUFFER is present in both versions of Spacy's code. I never really tried D3D on the official 1.72 build, on my Vista box it wouldn't go into fullscreen mode for some reason.

Lockable backbuffers and menu issues are related in that GDI wants the backbuffer lockable in order to write to the display. It is probably why Spacy added it. If you look through Nestopia's 1.23 changelogs they seem to have run into identical issues with it disrupting vertical sync. They "Solved" the issue by reinitializing the display when the menu bar is brought up. We will probably have to do the same. Unfortuantely there isn't a really simple "menu on" and "menu off" function to hook into.

see NES: Nestopia v1.23 :: AEP Emulation Page - Emulation News :: Online seit dem 1. April 1998 (http://www.aep-emu.de/index.php?name=PNphpBB2&file=viewtopic&p=7229)

mudlord

November 1st, 2007, 01:20

Ah okay, cool. Thanks for letting me know.

I have uploaded all the VBA builds I can find here:
http://mudlord.phpnet.us/vba/

Squall-Leonhart

November 1st, 2007, 01:21

been looking at that lockable buffer code. from what i read, you can lock and unlock the buffer, so setup an if statement for when the menu is showing to lock the buffer, and then unlock it when the menu is hidden.

i figure it would theoretically work :\

MasterPhW

November 1st, 2007, 02:32

Ah okay, cool. Thanks for letting me know.

I have uploaded all the VBA builds I can find here:
http://mudlord.phpnet.us/vba/
You forget the newly added VisualBoyAdvanceEd!
Btw: I have a long weekend, beginning now and I'll reformat my Laptop, after that I will continue to work on the help file. It's 25% done in my opinion.

mudlord

November 1st, 2007, 02:37

Sorry about missing that.

I'll upload it as soon as I get back from university today.

I can't wait to see the finished help file :) I bet it will be really nice ^^

djrobx

November 1st, 2007, 08:39

D3DPRESENTFLAG_LOCKABLE_BACKBUFFER is a parameter in the CreateDevice function where you set the video mode. Looking at the Nestopia sources there is a "Reset()" function that can be used to toggle it.

Ok, menu problem is fixed! Squall, give this version a try. As noted you must close the menu in order to enter fully hardware accelerated mode. On my system emulation runs slowly until the menu is closed. Personally, I think we should pause the emulation whenever the menu is opened and resume it when its closed.

http://www.djrobx.com/misc/VBAM-alpha-build13.zip

"13' corresponds to the SVN revision number, if anyone is interested.

NOTE: I have not tested the vba linking code at all, it most likely does not work yet.

Squall-Leonhart

November 1st, 2007, 22:25

djrobx, indeed, that would be the best way to go about it, all other emulators i use pause when a menu or setting dialogue is opened (snes9x, Pj64(+1.7)) so it would for in this case too.

djrobx, you might want to look at the snes9x source and try fixing thier issue with triplebuffering, when its enabled, opening a dialogue box sends the screen blank, i figure its the same issue. reason for this is i enjoy watching those jerks getting shown up :P.

i wonder what it will take to make TGB Duals linking method work for VBA, it'd be cool to have GB link support finally.

hey mudlord, how about implementing one of your nice AF filters ;)

edit
ok, tested that build,
the Direct3D mode isn't stretched to fit the full screen, there are black lines along the top and bottom, which aren't there in GDI, DDraw, or OpenGL.
i did notice the menu doesn't show up everytime i pressed escp to raise it. and there was obvious graphical corruption in the D3D mode when trying to raise the menu

i just realised, that this new version won't have the same SA* save format so you can't load 2 of the same rom with different save files without creating seperate directories for each.

mudlord, can you port over VBA-Links saving system, it uses some kind of detection system basically it assigns the first VBA window to *.sa1 and any other windows opened to *.sa2 *.sa3

OR

modify the detection method, so that when it detects more then 1 VBA-M open, it uses a specific folder for battery saves for Linked games.

so.. say for instance

if 1 window is open it saves/loads battery/state files to Battery/Savestate and uses the .SAV file type
if 2+ windows are open save/load battery/state files to Battery Linked/Savestate Linked. and uses the .SA* file type
if you don't get the gist of what im saying i'll explain it better on WLM.

its possible, it'll just take some heavy modification of the original VBA-L save methods :\

edit2
actually this looks to be useless for linking on a single pc,
unlike VBA-L, keyboard doesn't work in this one when its an inactive window, and from what i've seen it can't have 2 windows open at the same time, and still run at 100%, unlike VBA-L (yes, i disabled the filters.)

mudlord

November 1st, 2007, 23:06

hey mudlord, how about implementing one of your nice AF filters

Thank you for your suggestion, it has been noted and most likely will be implemented in the OpenGL renderer first, and then the Direct3D renderer.

Jeeez...I sound like a recorded message :(

MasterPhW

November 1st, 2007, 23:19

Hey, a little report to Emulation Problems with the posted VBA-M build:
The fixed [f1] rom of Iridion II does not freeze, but the non-fixed, original version [!] randomly freezes while playing on nearly all VBA builds also does with VBA-M CVS13...

Squall-Leonhart

November 2nd, 2007, 00:35

can you give a definite section where it always freezes?

MasterPhW

November 2nd, 2007, 00:49

Sadly no, because it ramdomly freezes in nearly all VBA builds,...

Squall-Leonhart

November 2nd, 2007, 01:48

All 1.8 versions can load Classic Nes Series games, but all builds including VBA-M, based on 1.7 fail to run them.

djrobx

November 2nd, 2007, 05:42

the Direct3D mode isn't stretched to fit the full screenYes, that is the same behavior I see, it is the way the code is currently designed (I already started debugging that last night). That will definitely be fixed. I'm more interested in solving the graphical corruption you notice. What kind of video card do you have? *edit* Oh, I see you mean the corruption is when the menu is raised. How is it when the menu is closed?
Hey, a little report to Emulation Problems with the posted VBA-M build:
The fixed [f1] rom of Iridion II does not freeze, but the non-fixed, original version [!] randomly freezes while playing on nearly all VBA builds also does with VBA-M CVS13...Thanks for the report. Not to worry, we have not yet integrated the "1.8" changes. Those will come in when we merge VBA-L which is based on the newer code. We are discussing that on the "Major bug..." thread. I was looking for feedback regarding the D3D changes.

Squall-Leonhart

November 2nd, 2007, 06:01

1.8 also has one other thing i had actually never noticed

the Game Overrides feature in the Emulator menu directly edits the Vba-over.ini

nifty :P
anyway, 1.8 uses to much cpu time to be viable for Linking, and VBA-M is pretty much the same, maybe mudlord will come up with a few performance tweaks, maybe some of the graphical work can be offloaded onto the video card instead of being done on CPU when Opengl or D3D is enabled.

djrobx

November 2nd, 2007, 06:35

anyway, 1.8 uses to much cpu time to be viable for LinkingIf I disable pixel filters and let D3D do the scaling, I am only using 18% CPU on a Pentium D 2.8ghz which by today's standards isn't even a very fast machine. Dual core CPUs are pretty common these days. There's always networking too. So linking is certainly still useful even if it's not on the same machine.

Hmmm, what would be interesting is allowing multiple emulators to run under one UI. I rather like that idea actually. Then you wouldn't have to try run them in windowed mode and try to arrange them on the screen. You would save a lot of CPU time by sharing one rendering resource. Unfortunately VBA is built using C++, but is structured more like a C program (lots of global variables), which may make creating multiple instances more difficult. OTOH most of the globals are the application status which can remain global anyway.

Definitely a "version 2" kind of thing but something I would be motivated to work on. Most of my emulating happens on a bigscreen. If firing up another GBA instance was as simple as pressing "Start" on controller #2 .. it would get a lot of use from me and my friends. :)

Squall-Leonhart

November 2nd, 2007, 07:19

try forcing VBA to single core, im seeing it maxing at 69%, where 1.7 maxes at 40%

djrobx

November 2nd, 2007, 08:03

the Direct3D mode isn't stretched to fit the full screen This is now fixed. Just an option "keep aspect" in Spacy's code that I had defaulted to true. try forcing VBA to single core, im seeing it maxing at 69%, where 1.7 maxes at 40% Some of the VBA-linking code is actually running when it shouldn't, which may be contributing to the slowness a little. Right now I want to focus on getting things working correctly, then we can look into optimizing the build for speed.

Squall-Leonhart

November 2nd, 2007, 08:32

well theres not actually an option to switch linking off.
but i've tested 1.8 to the same effect, 1.8 is most definitely a hungrier app.

MasterPhW

November 2nd, 2007, 09:50

If I disable pixel filters and let D3D do the scaling, I am only using 18% CPU on a Pentium D 2.8ghz which by today's standards isn't even a very fast machine. Dual core CPUs are pretty common these days. There's always networking too. So linking is certainly still useful even if it's not on the same machine.

Hmmm, what would be interesting is allowing multiple emulators to run under one UI. I rather like that idea actually. Then you wouldn't have to try run them in windowed mode and try to arrange them on the screen. You would save a lot of CPU time by sharing one rendering resource. Unfortunately VBA is built using C++, but is structured more like a C program (lots of global variables), which may make creating multiple instances more difficult. OTOH most of the globals are the application status which can remain global anyway.

Definitely a "version 2" kind of thing but something I would be motivated to work on. Most of my emulating happens on a bigscreen. If firing up another GBA instance was as simple as pressing "Start" on controller #2 .. it would get a lot of use from me and my friends. :)
I really like the idea of a multiscreen VBA, it would be some kind of splitscreen and really great to play on one PC.
It would also remove the sound problems with 2 different running VBAs!
Looking forward to this! ;)

Squall-Leonhart

November 2nd, 2007, 11:05

stay tuned for hardware accelerated Pixel Filtering ;)

djrobx

November 2nd, 2007, 22:05

I got the VBA link code to work (some missing things in VB.cpp) although unfortunately it doesn't seem to be nearly as compatible as the 1.8 beta that was released without the source code. I was able to successfully connect in some games, but not others.

We need to merge out-of-focus input, and the function that enumerates .INI and .SAV files, although I think we should use the standard names for the first instance (e.g. VBA.INI, VBA2.INI ... ) and so people don't need to rename their save files under normal usage.

Has anyone tried to email the authors of VBA-link to see if someone still has the better 1.8 beta code?

Hard core Rikki

November 2nd, 2007, 22:16

Has anyone tried to email the authors of VBA-link to see if someone still has the better 1.8 beta code?

No, but here's his profile (http://forums.ngemu.com/member.php?u=40495) (unseen since april).
PS: how about pokemonhacker? still active?

TheCloudOfSmoke

November 2nd, 2007, 23:58

You guys could try reaching him by e-mail: denopqrihgREMOVETHESECAPS(at)centrum(dot)cz (that's the e-mail found on the VBALink page (http://vbalink.wz.cz/).)

You also may be able to reach him on the VBALink forum (http://vbalink.wz.cz/phpbb2/index.php). (I don't know when the last time he's been on there though.)

mudlord

November 3rd, 2007, 00:06

Some of the VBA-linking code is actually running when it shouldn't, which may be contributing to the slowness a little.

well theres not actually an option to switch linking off.

I got the VBA link code to work (some missing things in VB.cpp) although unfortunately it doesn't seem to be nearly as compatible as the 1.8 beta that was released without the source code.

thank you for fixing that up. It really is appreciated. Sorry for the delay on re-recording additions and VBA-H, and the hardware graphics filters. I had some setbacks with needing a reformat, plus spending time in hospital last night, again.

I'll get the newest SVN and redo those patches.

MasterPhW

November 3rd, 2007, 19:20

mudlord

November 3rd, 2007, 22:41

Okay here, since you asked of one.....

Linking should be fully working in this SVN build. I'll start on rerecording again and then the hacking support, as well as those filters...

Squall-Leonhart

November 3rd, 2007, 23:24

After some research I know the reason for most of the known issues of the SVN-13 build and I want to share them:

-not working NES Games:
it have a special copy protection, which we need to include/emulate to get them running
-Iridion 2 crashes ramdomly:
game has a bad and mean SRAM check, fixes version removed it, so probably get save management working better, would also mean running this without crashes
-GBA Videos not running:
checks for the GBplayer, so probably a emulation of this thing would work here, too

BTW: Laptop is done, only need to install all the progs and then I will continue to write the help guide.
Any new compiled build to make pics of?

NES games will be fixed once the 1.8 core is ported in.

Main reasons why it's so slow: composites each layer to a separate buffer, composites sprites to an entire layer, does Z-testing on each pixel against sprites, and possibly worst of all tests all 128 sprites for visibility every scanline. Also color space issues and color conversion and just lack of general optimizations bog it down further.

just looking back to the thread and found that.
you think you can provide some improvements in that regard Mudlord?

mudlord

November 4th, 2007, 05:59

Hmm,

I've set up a dedicated VBA-M forum at:
http://mudlord.phpnet.us/forum

I also have updated the BountySource page (Nach added a special SVN browser), and updated the VBA fork page too.

you think you can provide some improvements in that regard Mudlord?

I've certainly got a interest in that, the main things is improving the core tho...

Squall-Leonhart

November 4th, 2007, 06:13

converting the core to dynarec was suggested a few pages back.

check this mate.

SourceForge.net: Detail: 1292942 - CPU emulation optimization patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1292942&group_id=63889&atid=505531)

mudlord

November 4th, 2007, 07:26

I looked at that optimization patch. Looks quite cool, I might do a build with it added.

Squall-Leonhart

November 4th, 2007, 08:01

oooooh, i just went through the vba.h source and it supports VBA savestate version 9 saves.

maybe i was using a build which supported that :\ with my old states

mudlord

November 4th, 2007, 08:03

maybe i was using a build which supported that :\ with my old states

Hmmm, maybe...*ponders*

ppr:kut

November 4th, 2007, 17:52

Hey guys!
It's awfully great somebody is taking on work on VBA.
Just one question: You guys seem to work on a windows-only version.
Are there any plans to make it also work under linux/mac?

djrobx

November 4th, 2007, 17:55

Regarding code optimizations. I ran a profiler on the code and I'm 99% sure I see why our version is slower than the standard 1.7 versions: Kode54's sound updates. The VBA code adds sound to its buffers one byte at a time. The filtration functions were then bolted onto that function. The filtration functions were written with "higher level" C++ mentality (layers of classes and overriden functions). There is also some sort of dynamic "sample rate" adjustment in there that deals with floating point numbers.

Given the massive number of times the function gets called those layers slow things down quite a bit even when sound filtering is off. The layers themsleves are fine but I think the function should be getting called in chunks at the output phase. Some of the code is directly tied into the core too, I'm not sure of the reasoning behind that.

I have to study the code a bit more to figure out what's going on and find a more efficient way of doing it.
It's awfully great somebody is taking on work on VBA.
Just one question: You guys seem to work on a windows-only version.
Are there any plans to make it also work under linux/mac?Our initial goal is to consolidate the features and hard work that other devs have already done into a single high quality app that the community as a whole can pick up and move forward with. We're still working on getting this "base" nailed down.

I'm actually typing this response on my Mac. So I'm definitely gung-ho on the idea of getting Mac support 100% functional. At my last job I was a linux dev working on the pluto-home project, so I have a lot of linux experience as well.

Ideally experts in those fields (linux/mac) will step up and help us out with those things. We're humans and can only do one thing at a time. At a minimum I would expect the cross-platform SDL support to work as it does in the official build.

mudlord

November 4th, 2007, 20:20

Ideally experts in those fields (linux/mac) will step up and help us out with those things. We're humans and can only do one thing at a time. At a minimum I would expect the cross-platform SDL support to work as it does in the official build.

Indeed. Luckily now, we have Nach and Jonas Quinn helping us now too, from the ZSNES project. Nach is quite a expert in Linux and SDL development, and Jonas is well known for his ability to bust bugs with ZSNES. So, we will definately have help in making this project cross-platform.

Squall-Leonhart

November 4th, 2007, 21:53

VisualBoy Advance 1.8 beta source (http://www.techiedownloads.com/downloads/VBA/VisualBoy%20Advance-1.8.0%20source.tar.gz)

source is up.

you punks better be happy, took me 4 hours to get every single file one by one.

edited.

Source has been updated.

Mudlord, get it again, the other one had some issues with the gb files somehow when i saved them it wasn't the full file... probably cut off due to server timeout.

Hard core Rikki

November 4th, 2007, 21:55

Mmh, can't wait for a more accurate and faster core ;)

mudlord

November 5th, 2007, 01:16

Thanks Squall!

I have been waiting eagerly for this ^^

TheCloudOfSmoke

November 5th, 2007, 04:05

I had a question, are you guys just merging all of the builds, or are you all also going to add new features/bug fixes as well? I was asking because I was hoping that someone could add Goodmerged 7z support (even though I don't think that Goodmerge supports GBA roms, it would still be useful to be able to open a compressed file with multiple roms)? Sorry if you guys already answered this question, there's a lot to read within the last few days. :p

Squall-Leonhart

November 5th, 2007, 04:56

Thanks Squall!

I have been waiting eagerly for this ^^

you'll need to redownload

as far as i know, only the GB files and non win32 files were affected

same link above in a fruity new gzip and tar format for extra compression

mudlord

November 5th, 2007, 04:56

I had a question, are you guys just merging all of the builds, or are you all also going to add new features/bug fixes as well?

Both. We will be merging the builds, as well as adding new features and busting old bugs. I know I got some plans for the D3D9 and OpenGL renderers.....

I was asking because I was hoping that someone could add Goodmerged 7z support (even though I don't think that Goodmerge supports GBA roms, it would still be useful to be able to open a compressed file with multiple roms)? Sorry if you guys already answered this question, there's a lot to read within the last few days.

That would require a ROM browser at least, to effectively manage those ROMs in compressed archives. I haven't heard much about Goodmerge tho..but it definately is feasible. Its just some UI work to make the ROM browser, than some rewrites to the archive parsers to handle multiple files.

EDIT: same link above in a fruity new gzip and tar format for extra compression

Wonderful. Luckily WinRAR handles them fine.....

TheCloudOfSmoke

November 5th, 2007, 05:25

Well, you guys are Gods. I was really sad to hear that Forgotten decided to drop the project because the VBA was and still is a great emulator and I knew that the project wouldn't last for long without him in charge. I'm excited to hear that you guys are taking over. Much luck to you guys and thanks. It's great to see dead open source projects being put to good use. :D

mudlord

November 5th, 2007, 06:03

Well, you guys are Gods :cool:

Thats extremely kind of you to say..I'm flattered. Really :D

I was really sad to hear that Forgotten decided to drop the project because the VBA was and still is a great emulator and I knew that the project wouldn't last for long without him in charge. I'm excited to hear that you guys are taking over. Much luck to you guys and thanks. It's great to see dead open source projects being put to good use.

Well, I hope you folks find it useful.

PS: Squall, here is your VBA compiled from the official VBA CVS source code server on SourceForge. It has the 1.8.0 emulation cores present. I had to modify it somewhat due to someone using YASM to link 2xSaiMMX.asm (for 64 bit compatibility, I assume)

Squall-Leonhart

November 5th, 2007, 06:49

tah Mudlord,

feedback on this, the core is newer then the july 2007 wip, Megaman Zero is fixed, as is other affected megaman games.
seems to perform slightly better then other 1.8 beta's
VBA Bios now supports the function required for Yugioh GX - Duelist Academy, bios may still be required for other games.

djrobx

November 5th, 2007, 06:57

I was asking because I was hoping that someone could add Goodmerged 7z support (even though I don't think that Goodmerge supports GBA roms, it would still be useful to be able to open a compressed file with multiple roms)? Kode54's build had support for this. The code is there but I have to track down the libraries he was using.

ppr:kut

November 5th, 2007, 10:10

I read that you are collecting patches and just remembered, that Debian has the latest cvs-version in its testing-repository, including some patches. They are of course linux-related and more style-issues than features, but probably worth looking at.

mudlord

November 5th, 2007, 10:43

They are of course linux-related and more style-issues than features, but probably worth looking at.

Linux related? Are they based off the newest emulation cores? I know Nach will be interested in this.

ppr:kut

November 5th, 2007, 11:04

Linux related? Are they based off the newest emulation cores? I know Nach will be interested in this.
It's the latest vba cvs-snapshot from sourceforge, they call it 1.8.0.
Available here:
Debian -- Details of package visualboyadvance in lenny (http://packages.debian.org/lenny/visualboyadvance)

Squall-Leonhart

November 5th, 2007, 23:05

we already have that.

Triple buffering should be fixed in Opengl.

mudlord

November 6th, 2007, 09:32

ty squall, ill compile a build for the others to play with....

mudlord

November 6th, 2007, 09:52

Built from SVN 21. This is the output of your OpenGL fix. I had to fix one error in your code due to a lack of a parameter. :/

Enjoy :|

Squall-Leonhart

November 6th, 2007, 12:48

i noticed 2 issues
1. keyboard won't move character at all.
2. if you set to full screen 1024x768 in a 1280x1024 screen it doesn't change the screen mode, it just displays it at 1024x768 at the top left corner of the screen.

i also noticed that the 1.8 D3D9 render actually doesn't do flipping in GDI, (theres actually no mention of gdi anywhere there.)

problem is with opengl theres no triplebuffering extension so we'll need to find a way to have it flip to opengl instead of gdi, as thats the only way we;ll get triple buffering in it.

mudlord

November 7th, 2007, 05:56

problem is with opengl theres no triplebuffering extension so we'll need to find a way to have it flip to opengl instead of gdi, as thats the only way we;ll get triple buffering in it.

hmmmm, we'll need to look at it.

Currently the new emulation cores are in, its just a matter now of tuning them and fixing up the update patches.

Lathain Valtiel

November 8th, 2007, 00:44

Just so you know, linking still doesn't work.

Or at least connecting doesn't. It just pops up an error with a blank message. You know, standard red X stuff.

Hilariously, the 1.8.0 beta can connect to VBA-M SVN21. But the SVN can't connect to itself. The mind boggles and thinking of how that can be gives me a terrible headache. Damned lack of 1.8 link source.

Cypherswipe

November 8th, 2007, 01:25

I'd really like to see some of the cheat hunting features of VBA-H (hackers edition) added. VBA-H is discontinued & all the sites which used to have it seem to be dead now. However, I still have a copy of the program (but not the source) & can upload it somewhere if that would help. You could also try to contact kenobi & labmaster, since they're the ones who developed it. The 2 biggest/most noticable improvements over the normal VBA cheat searching is a vastly improved searching interface: http://allspark.net/cypherswipe/VBAH-dialog-1.png and the ability to edit a code from the cheat list (instead of having to add an altered copy of the code, then delete the original, like you have to do to change a code in normal VBA builds).

mudlord

November 8th, 2007, 02:55

Hilariously, the 1.8.0 beta can connect to VBA-M SVN21. But the SVN can't connect to itself. The mind boggles and thinking of how that can be gives me a terrible headache. Damned lack of 1.8 link source.

Your right, that is odd. Even weirder, is that the 1.8.0 emulation cores were only added at revision 23, according to the internal subversion server logs, and not revision/SVN 21.

However, I still have a copy of the program (but not the source) & can upload it somewhere if that would help. You could also try to contact kenobi & labmaster, since they're the ones who developed it.

Not to worry, I have a copy of the VBA-H source code.

So mainly, the only worthy additions you see are the additional cheat searching functions?

Cypherswipe

November 8th, 2007, 03:51

Yeah. The pages that talk about VBA-H mention some extra code compatability but 1) I've never noticed a difference 2) Many of those may have already been added into VBA 1.8x.

VBA is pretty close to perfect already, there are only 3 issues I can see that need dealt with.
1) The reduced speed of 1.8x, but people have mentioned this already.
2) The cheat search enhancements from VBA-H.
3) There's a long standing bug about VBA not accepting legitimate cheat codes for some GB/GBC games because forgotten had made the emu based on some inaccurate documents. However, that only affects some codes in some games, and doesn't affect GBA games at all, so it's not a big deal.

Squall-Leonhart

November 8th, 2007, 04:11

1.8 source is based off the latest WIP source, so it has additional bios emulation as well as has the megaman issues of the currently available built wip fixed,
past that, it also has some performance improvements over previous 1.8wip's

additionally, Classic NES games work.

Mudlord, just a reminder, any improvements made to the core or graphics for that matter, we should notify one of the VBA devs to look over to be added to the main branch. if possible.

djrobx

November 8th, 2007, 04:51

Hilariously, the 1.8.0 beta can connect to VBA-M SVN21. But the SVN can't connect to itself. The mind boggles and thinking of how that can be gives me a terrible headache. Damned lack of 1.8 link source.It does work ... sometimes. Connections in particular are not consistent, but they do work sometimes. I really wish the 1.8 beta sources were available. I haven't put much effort into debugging that yet. The result is exactly the same on our newer 1.8 based core.

VBA is pretty close to perfect already, there are only 3 issues I can see that need dealt with.For me, HQ3x or 4x is a must. Fullscreen looks like ass without it. 60fps vsync is a must. The sound interpolation makes things sound much better as well. The assembler core HQ4x is so fast it's barely different from no interpolation at all!

The official 1.8's direct3d implementation is pretty broken, you can't set fullscreen modes without going to DirectDraw.

I also don't like that almost all of the VBA builds wipe out your game controller settings if your gamepad isn't plugged in.

That's the beauty of open source -I took VBA, fixed these things, and am contributing it back to the community.

Overall the new 1.8 core is working well. There are some remaining issues with the Blargg's audio core integration. Worst case I may revert to the "official" audio core and merge in just the sound interpolation. I will say 1.8 "plays" a lot better. Games don't "feel" nearly as sluggish. Super Monkey Ball is a good example. With the 1.6 core it was very sluggish, under 1.8 gameplay is very fluid.

Squall-Leonhart

November 8th, 2007, 05:04

djrobx, can you post your build up for me to test?

mudlord

November 8th, 2007, 10:08

Since you asked....:/

Squall-Leonhart

November 8th, 2007, 14:28

damn, Opengl needs a lot of work now, D3D is running well, but OGL is running like ass as well as locking up the screen when you exit it.

mudlord

November 8th, 2007, 19:32

but OGL is running like ass as well as locking up the screen when you exit it.

Figures....erstwhile, while adding your anisotropic filtering (which the actual filtering code is only 3 lines), screen goes white. Extremely strange, even when rendering to a textured quad. Sorta explains how my AF code didnt work while its running like crap for you...Gonna see about this though...

C0K3

November 9th, 2007, 07:03

well, if you need an spanish translator, i'm on. :D

Hiei-YYH

November 9th, 2007, 09:39

something that need to be changed in vba is the cheat window, mainly to one like pj64 or no$gba.

ShakirMole

November 9th, 2007, 11:34

It's excellent to see good improvements are coming for VBA (the best emu IMO)
Good luck guys

mudlord

November 9th, 2007, 12:09

something that need to be changed in vba is the cheat window, mainly to one like pj64 or no$gba.

Like a cheat DB or something?

Thats something that needs to be of a consensus, as I am hearing that the improved VBA-H cheat searching features might be nice, and then I'm hearing this. Honestly, I think you could post on my forum and I'm sure I and the other devs could have a think about this :). Afterall, the forum is meant to be for VBA-M development, its kinda vacant atm, without me, Nach, or DJRobX...

It's excellent to see good improvements are coming for VBA (the best emu IMO)
Good luck guys

Thank you, I hope you guys like the improvements we got planned. :)

ShakirMole

November 9th, 2007, 13:38

just wanted to know how to convert the files from 1.8.06 (latest build) like save files and cheat files to be played in 1.7.4 since it's a little slow for me in some games

Cypherswipe

November 9th, 2007, 15:35

It should be possible to have both cheat things. VBA has 2 cheat oriented windows, the cheat searcher & the cheat list. I don't know the technicalities of programming it, but in theory it should be possible to have a no$gba-like cheat -list- window & the enhanced cheat -search- window from VBA-H in the same program, without conflicting with each other.

Hiei-YYH

November 9th, 2007, 16:55

Like a cheat DB or something?

Thats something that needs to be of a consensus, as I am hearing that the improved VBA-H cheat searching features might be nice, and then I'm hearing this. Honestly, I think you could post on my forum and I'm sure I and the other devs could have a think about this :). Afterall, the forum is meant to be for VBA-M development, its kinda vacant atm, without me, Nach, or DJRobX...

Thank you, I hope you guys like the improvements we got planned. :)

not a db, just a better cheat list window, because pasting long codes are a pain in the ass in vba, a lot of useless lines since it can be stored in just 1 line. and yet, there is a line limit, which only make this worst.

what's your forum anyway?

MasterPhW

November 9th, 2007, 20:24

not a db, just a better cheat list window, because pasting long codes are a pain in the ass in vba, a lot of useless lines since it can be stored in just 1 line. and yet, there is a line limit, which only make this worst.

what's your forum anyway?

http://mudlord.phpnet.us/forum is the forum.
But a real Cheat database, like in PJ64, saved in a special INI would also be great.
I would be your guy to create it! :)

Squall-Leonhart

November 10th, 2007, 00:46

just wanted to know how to convert the files from 1.8.06 (latest build) like save files and cheat files to be played in 1.7.4 since it's a little slow for me in some games

do a battery save and load from that in the old version.

cheat lists can't be backported afaik.

they should all be supported in a build made off the official branch which you can get here

http://forums.ngemu.com/attachment.php?attachmentid=148159&d=1194242605

TheCloudOfSmoke

November 10th, 2007, 01:04

Shouldn't this get on front page news so the project can get some more attention in the emulation community and that people can help out in the project? I think that many people would be interested in a potential new VBA build that includes all of the features from various VBA builds. BTW: I'm building up a list of suggestions if you're up for it mudlord. :)

Squall-Leonhart

November 10th, 2007, 01:21

a few kinks are arising.

the current revision, the audio becomes corrupted and input no longer works when you load a save state
Opengl doesn't have triplebuffering support, as the fliptogdi method was removed, there might be a way yet to include tb without using fliptogdi, which based off the D3D in the current build, would actually improve performance when TB is enabled

mudlord

November 10th, 2007, 01:31

Shouldn't this get on front page news so the project can get some more attention in the emulation community and that people can help out in the project?

This is on the front page. :)

I think that many people would be interested in a potential new VBA build that includes all of the features from various VBA builds. BTW: I'm building up a list of suggestions if you're up for it mudlord.

Lovely. Post the list on the VBA-M forum. That way, its bound to get my attention. Also, you could post it up on the VBA-M BountySource version tracking system.

Oh and we finally hit 50 revisions. Not bad for just a weeks work.

TheCloudOfSmoke

November 10th, 2007, 06:32

This is on the front page. :)

Lol. Well, upon looking on the front page again, I see that it finally made it to the front page. That's great! I looked at it earlier today and didn't see it, maybe it's because I didn't clear my temporary internet files. :emb:

Lovely. Post the list on the VBA-M forum. That way, its bound to get my attention. Also, you could post it up on the VBA-M BountySource version tracking system.

Oh and we finally hit 50 revisions. Not bad for just a weeks work.

Will do. :)

Lord Budweiser

November 12th, 2007, 05:11

BUMP!

One thing to consider about VBALink is that the newest version isn't exactly better. it only got better wireless link support if I recall correctly, but there are bugs with standard link (to which version 1.7.3 is recommended, even on the official VBALink forum - maybe you should try to contact the VBALink author there); for example, sometimes errors (Black screen with error message) occurs when linking Pokémon Ruby to pokémon LeafGreen on VBALink 1.8.0 (the "source" of the problem is probably Pokémon Ruby), whereas it doesn't happen in version 1.7.3. The error occurs when Ruby tries to see LeafGreen card or when switch pokémon in battle (Yes, I tried the same settings on both versions, and some other settings too). So, I suggest to keep the 1.7.3 source for standard link and maybe 1.8.0 source for wireless (I haven't used wireless yet, to speak the truth).

And I second Squall-Leonhart, gb/c link would kick some major ass.

Hope this info was useful.

Have a nice day.

mudlord

November 12th, 2007, 10:30

Well, we are aiming to keep things stable, so the 1.7.3 VBALink code is sticking for now :)

It would be nice if all bugs are directed to my forum or if all bugs are reported on the version tracker on the BountySource page. :)

Squall-Leonhart

November 12th, 2007, 12:14

djrobx

November 12th, 2007, 18:51

I was asking because I was hoping that someone could add Goodmerged 7z support (even though I don't think that Goodmerge supports GBA roms, it would still be useful to be able to open a compressed file with multiple roms)? Sorry if you guys already answered this question, there's a lot to read within the last few days.VBA-M now has 7zip and RAR support, although support for these behaves just like Zip support in that it will select the first valid rom image in the archive. As mudlord noted, to support goodmerging, the UI and command line interfaces would need to be extended to allow picking a file from an archive.

the current revision, the audio becomes corrupted and input no longer works when you load a save stateYou probably saved the state with the Blargg apu core builds. When I reverted back to the official audio core, I noticed that the patch removed some of the entries in the save state procedure.

That means save states created in the older builds are not usable in current builds.

In other words, due to an oversight in the Kode54 patch implementation, save states are not comatible with the official build format. This is now fixed but your older save states aren't usable.

Squall-Leonhart

November 13th, 2007, 03:00

actually Rob, that was using a savestate from 1.7.2 in VBA-M

djrobx

November 13th, 2007, 06:23

What VBA-M build? Any of the gb-apu builds (which is almost any one up till revision 47) will likely have compatibility problems with savestates from any VBA version other than itself. Past 47 it should behave identically to the official VBA 1.8 beta build, the save code is back to being exactly the same.

Squall-Leonhart

November 13th, 2007, 06:37

it would have to be before build 45

i haven't had a compiled build 47 or later to test

mudlord

November 13th, 2007, 08:17

There, here's a compile for you to try Squall. Based on SVN revision 57.

Currently working on adding VBA-H based functionality, specifically the updated cheat searching algorithms. Nothing too hard, just time consuming lol.

Re-recording will take a while to implement (due to so much changes to the core), hopefully nitsuja can help us move in the right direction with that, since he's the dude that added it originally to VBA.

EDIT: Sorry, I had to remove RAR support, due to licensing restrictions on the RAR algorithm. Don't wanna get sued...

ArtVandelae

November 15th, 2007, 16:49

I found a very minor issue in Sound.cpp

Line 281: { &soundDSBValue, sizeof(int) },

should be: { &soundDSBValue, sizeof(u8) },

mudlord

November 15th, 2007, 19:47

Will fix, thank you for the correction.

squallz

November 15th, 2007, 22:45

MasterPhW

November 15th, 2007, 22:49

Hey, great work.

I found a small bug:

When you're configuring the directories, the tab focus order is wrong:

http://forums.ngemu.com/attachment.php?attachmentid=149853&stc=1&d=1195166623

I hope you get what I mean, my english is really poor.
It would be good to know which version you are using.
Did you tried SVN build 86? Probably it's already fixed?

squallz

November 15th, 2007, 23:03

Sorry.
It's SVN build 87.

(This one. (http://vba-m.ngemu.com/vbacompiles/VisualBoyAdvance87.rar))

djrobx

November 15th, 2007, 23:05

When you're configuring the directories, the tab focus order is wrong:
Fixed (SVN 89)

Squall-Leonhart

November 16th, 2007, 01:50

O.o more people involved ^^

mudlord

November 16th, 2007, 02:08

Yes, and I managed to find some shreds of VBASmooth source code.

However, the catch is, its in XPort's XBOX port of VisualBoyAdvance :/...

Anyways, SVN 89 (http://vba-m.ngemu.com/vbacompiles/VisualBoyAdvance89.rar) as Squall requested.

TheCloudOfSmoke

November 16th, 2007, 12:11

I tried to send an e-mail over to Martin at emu64 (the owner of emulation64) several weeks ago to see if he can find the last copy of the source that was hosted there, yet I haven't managed to get a response back from him. Can someone who is a member there on their forums get the word out to see if they can help in retrieving the source to VBA Smooth?

djrobx

November 16th, 2007, 20:57

The most useful bit of code in VBASmooth is the snippet that allows it to load Kega Fusion video filter plugins. Unless I'm missing something, I'm not really sure we really need it for anything else.

mudlord

November 16th, 2007, 20:58

The most useful bit of code in VBASmooth is the snippet that allows it to load Kega Fusion video filter plugins. Unless I'm missing something, I'm not really sure we really need it for anything else.

Indeed, I guess the main attraction was that one feature.

Squall-Leonhart

November 16th, 2007, 23:42

Rob, theres still an issue with reenabling sound after disabling it.

djrobx

November 17th, 2007, 00:31

Rub, theres still an issue with reenabling sound after disabling it.Sorry I've been a little busy. I will look at it. I've been trying to get everything working on my Mac Pro. I installed Vista x64 to take advantage of all my RAM. It almost works perfectly now, but I have issues with the XBCD drivers and the NVidia 7300GT was performing horribly with Vista's Aero. Funniest part about all this? In googling for solutions, your name kept coming up on posts for both things. I can't seem to get away from you! :)

Squall-Leonhart

November 17th, 2007, 00:59

Reboot > F8 > Disable Hardware Signing (Requirements)

yeah i actively work on parts of XBCD when i get the time, atm im trying to work out why only Constant, Ramp and Square work.

mudlord

November 17th, 2007, 04:27

Thanks to XPort (a very good Xbox/Xbox 360 programmer, that does homebrew coding for these systems, as well as for porting many emulators to the Xbox systems), I have original copies of the VBASmooth patch source code, as well as PokemonHacker's GBA source, and many other source redistribitions.

Looks like now RPI Kega Fusion filter support will be possible now :).

EDIT: Actually started to implement the filters now :)

mudlord

November 17th, 2007, 06:09

And now Kega Fusion filters are implemented! Expect a SVN commit very soon.

djrobx

November 17th, 2007, 06:20

Awesome!

mudlord

November 17th, 2007, 07:21

SVN 92 (http://vba-m.ngemu.com/vbacompiles/VisualBoyAdvance92.rar)

This is bundled with KarlKox's Kega Fusion RPI filter files...
And source committed to SVN.

djrobx

November 17th, 2007, 10:16

Rob, theres still an issue with reenabling sound after disabling it.Ok, this should be fixed now (SVN 93)

mudlord

November 17th, 2007, 10:50

And there's a compile of it in the usual spot for Squall to try.... (http://vba-m.ngemu.com/vbacompiles/VisualBoyAdvance93.rar)

Squall-Leonhart

November 17th, 2007, 11:03

get on msn or irc

bout time i posted some new bugs up.

oh mudlord, just to tick you off

the filters don't work :P

it just breaks the display

good work rob, sound reenables fine now.

mudlord

November 17th, 2007, 12:05

What the hell? I tested them out thoroughly, and they work for me fine in DirectDraw....

I've tested them extensively in windowed mode and the only KF filter I found to fail was the Eagle filter..

EDIT: Just tried fullscreen mode, and they still work for me...

Desktop bitdepth is 16-bit

EDIT2: Confirmed, Kega filters will work only in 16 bit colour.

GSDragoon

November 18th, 2007, 03:21

get on msn or irc

bout time i posted some new bugs up.

oh mudlord, just to tick you off

the filters don't work :P

it just breaks the display

good work rob, sound reenables fine now.

I just got the same thing on FFIV. Using the 4x size I went to hit "Select Filter Plugin". From there the screen messed up. Hit select filter plugin again and the selection screen shows up, but it doesn't seem to change anything.

EDIT: 32-bit color, but it actually crashes when you select the checked menu item "Filter Plugin." The corruption goes away when I select magnifaction: HQ4X.

mudlord

November 18th, 2007, 03:30

Again, I would like to repeat: Kega Fusion filters ONLY work in 16-bit colour modes.

Squall-Leonhart

November 18th, 2007, 06:52

for now heh heh

there is a way though, just like Fusion does, to output a 16bit image, while in a 32bit display mode.

might be worth looking into

mudlord

November 18th, 2007, 08:20

Indeed so, but I rather not use hacks.

There is a way though, to force the renderers to use 16 bit in a 32bit desktop, so that your desktop settings don't get affected. Tried this out today while rewriting some GFX code, and suffice to say, worked quite well as a workaround. Might add it as a extra INI setting....

Squall-Leonhart

November 18th, 2007, 09:45

it wouldn't be a hack

the GBA has a 15bit colour output, rendering it in 32bit is the hack

mudlord

November 18th, 2007, 09:48

...And if thats the case, why do we need 32-bits precision when the GBA needs only 16-bit? Thats whats got me thinking. Honestly, I'm starting to think 32-bit usage in this emulator is only the placebo effect working, unless I get objective evidence to prove 32-bit is "better". Afterall, isn't it the point of any emulator to do it accurately?

Squall-Leonhart

November 18th, 2007, 15:04

just do it how Fusion does
render a 16bit image (and make it do so while still maintaining 32bpp depth)
it Kega did it, it shouldn't be hard.

djrobx

November 19th, 2007, 01:55

Again, I would like to repeat: Kega Fusion filters ONLY work in 16-bit colour modes.What I'd do is force the emulator to render to 16 bit, then convert the output to 32 bit. The code is already there to force the input to 16 bit (used by HQ3x and HQ4x). I can implement this if you'd like, should be pretty easy.

mudlord

November 19th, 2007, 05:19

Yeah, I seen your colour hacks for HQ3x/HQ4x. First time around they didnt work. I might have a relook again.

EDIT: Second time around, failed too. Sigh, I found the only effective manner, like VBASmooth, was to enforce 16-bit rendering.

djrobx

November 19th, 2007, 07:37

Forcing 16 bit rendering just forces the emulator to produce a 16 bit source regardless of the display mode. We will need to add code to convert the 16 bit output of the filter to 32 bits. Don't worry, I'll take care of it.

-- Rob

Ok, committed (SVN 95).

I had to add some strange math to the height values in order for the RPI filter to render the full frame (in either 16 or 32 bit mode).

New glitch I noticed when testing this: Once in 32 bits, sometimes the emulator doesn't want to go back to 16 bits. The only way I could get D3D to go back to 16 bits was to switch to DirectDraw mode. Will investigate later.

mudlord

November 19th, 2007, 09:37

I had to add some strange math to the height values in order for the RPI filter to render the full frame (in either 16 or 32 bit mode).

Yeah, I seen the funky math you did in rpi.cpp. Thanks for helping me implement this, btw :).

New glitch I noticed when testing this: Once in 32 bits, sometimes the emulator doesn't want to go back to 16 bits. The only way I could get D3D to go back to 16 bits was to switch to DirectDraw mode. Will investigate later.

Does it change when you go to fullscreen, or choose the OpenGL renderer? Speaking of which, I am working on a new texture-based D3D9 renderer, instead of it writing to surfaces. It most likely will be implemented as a extra renderer object, instead of a replacement.

djrobx

November 19th, 2007, 15:55

Yeah, I'm going to have to see if I can find the source to an RPI filter to find out what's up with that height parameter. The behavior is consistent across all the various filters, and everything seems to work OK but the possibility of overshooting buffers makes me nervous.

Does it change when you go to fullscreen, or choose the OpenGL renderer?The current OpenGL renderer only supports 32 bits (BGR pixel format). Picking one of the listed fullscreen modes is supposed to set it to 16 bits in D3D9 mode. But as it stands even picking a mode from the full list of video modes ("Select...") sticks at 32 bits in D3D9 mode. It's probably something simple, I just had never noticed this issue until now.
I am working on a new texture-based D3D9 renderer, instead of it writing to surfacesCool! We still need to add full-screen modes to the OpenGL renderer, too.

-- Rob

TheCloudOfSmoke

November 19th, 2007, 19:44

Yeah, I'm going to have to see if I can find the source to an RPI filter to find out what's up with that height parameter. The behavior is consistent across all the various filters, and everything seems to work OK but the possibility of overshooting buffers makes me nervous.

Index of /Files/Emulation (http://sbougribate.free.fr/Files/Emulation/)

Welcome to the official 2XPM Homepage! (http://2xpm.freeservers.com/)

Eidolon's Inn : Plugins (http://www.eidolons-inn.net/tiki-view_forum_thread.php?comments_parentId=3569&topics_threshold=0&topics_offset=121&topics_sort_mode=lastPost_desc&topics_find=&forumId=10)

djrobx

November 20th, 2007, 01:41

Thanks, Cloud!

That makes the problem pretty clear.

lq3x:
for (y = 3; y < rpo->SrcH; y++)

lq4x:
for (y = 4; y < rpo->SrcH; y++)

scale2x:

for (y = 2; y < rpo->SrcH; y++)

Makes no sense at all why you'd skip "scaleFactor" lines of the source. I hope all rpi's are implemented with this "feature" uniformly. :/

-- Rob

Squall-Leonhart

November 20th, 2007, 06:11

the save type detection is broken on Pokemon Blue, Red Yellow and Green
it disables saving because of this.

also
Borders are not loaded from Gold or Silver
this dates back to the 1.8wip source but is not an issue in the official beta 3

mudlord

November 20th, 2007, 12:24

Uploaded builds of SVN 104 (http://vba-m.ngemu.com/vbacompiles/VisualBoyAdvance104.rar)

Includes new SDL-based Win32 build (http://vba-m.ngemu.com/vbacompiles/vbam-sdlwin32104.rar). Note that it is command-line based for commands.

MasterPhW

November 20th, 2007, 13:20

Btw: again the message:
"Error:
Couldn't create socket!"
if I want to use my old VBA.INI...

djrobx

November 20th, 2007, 14:32

Btw: again the message:
"Error:
Couldn't create socket!"
if I want to use my old VBA.INI...It means you have bad network play settings. You probably have a port specified that your system can't bind to. Go into the netplay settings and disable the TCP/IP netplay. It should just show an error and let you continue whatever you were doing. If you can post your VBA.INI I can take a look to see exactly what your issue is.

MasterPhW

November 20th, 2007, 15:28

It means you have bad network play settings. You probably have a port specified that your system can't bind to. Go into the netplay settings and disable the TCP/IP netplay. It should just show an error and let you continue whatever you were doing. If you can post your VBA.INI I can take a look to see exactly what your issue is.

The funny thing about that is, I've never changed anything in these network settings! I've started VBA-M and after a new version was released I've replaced the binary with the new binary and then I've got this message. And I can't even start VBA-M, after this message appears, so I can't change anything in the config. Have to create a clean install to get it working. Just deleting won't work!
Btw, here's my INI:
[preferences]
language=0
languageName=
frameSkip=1
gbFrameSkip=0
autoFrameSkip=0
vsync=0
synchronize=1
stretch=0
video=0
defaultVideoDriver=1
fsAdapter=0
fsWidth=0
fsHeight=0
fsColorDepth=0
fsFrequency=0
renderMethod=1
windowX=0
windowY=0
useBios=0
skipBios=0
soundEnable=783
soundOff=0
soundQuality=2
soundEcho=0
soundLowPass=0
soundReverse=0
soundVolume=0
soundInterpolation=0
ddrawEmulationOnly=0
ddrawUseVideoMemory=0
tripleBuffering=1
d3dFilter=0
glFilter=0
glType=0
filter=0
LCDFilter=0
disableMMX=0
disableStatus=0
showSpeed=0
showSpeedTransparent=1
gbPrinter=0
pauseWhenInactive=1
useOldSync=0
captureFormat=0
removeIntros=0
recentFreeze=0
autoIPS=1
disableSfx=0
saveType=0
ifbType=0
flashSize=131072
agbPrint=0
rtcEnabled=0
autoHideMenu=0
skinEnabled=0
skinName=
borderOn=0
borderAutomatic=0
emulatorType=0
colorOption=0
priority=2
autoSaveCheatList=0
gbPaletteOption=0
gbPaletteCount=48
gbPalette=FF7FB5568C310000FF7FB5568C310000FF7FB556 8C310000FF7FB5568C310000FF7FB5568C310000FF7FB5568C 310000A4
rewindTimer=0
recent0=
recent1=
recent2=
recent3=
recent4=
recent5=
recent6=
recent7=
recent8=
recent9=
joypadDefault=0
autoLoadMostRecent=0
cheatsEnabled=1
fsMaxScale=0
throttle=0
pluginName=
saveMoreCPU=0
LinkTimeout=1000
Linklog=0
RFU=0
linkEnabled=0

diediedie

November 26th, 2007, 19:10

I was able to sucessfully compile vba-m with vs2008 i thought you would like to know that it worked

mudlord

November 26th, 2007, 23:53

So VBA-M now compiles with Orcas....Is there any chance you can send us the VC2008 project files for integration?

diediedie

November 27th, 2007, 06:54

VS 2008 Project Files (http://rapidshare.com/files/72571439/vs2008vbamprj.zip)

There you go didn't have to make any changes at all for it to work.
Project files are the rtm version

mudlord

November 27th, 2007, 09:46

Thanks for the files. Uploaded to SVN.

Dualscreenman

December 5th, 2007, 15:59

Was poking around the source and found an else if statement which I promptly transformed into a nicer switch statement. ;D

mudlord

December 5th, 2007, 21:17

Thanks, I applied your RTC emulation patch to the current source.

Dualscreenman

December 6th, 2007, 02:19

Two more, heh.

mudlord

December 6th, 2007, 03:07

Noted and patch applied

Squall-Leonhart

December 12th, 2007, 11:11

@Spacey
You broke full screen with your menu 'fix'

when you go full screen the black bar where the menu is supposed to be is still there forcing the entire screen down.

Spacy

December 12th, 2007, 17:09

@Spacey
You broke full screen with your menu 'fix'

when you go full screen the black bar where the menu is supposed to be is still there forcing the entire screen down.

What render mode? What resolution?

Squall-Leonhart

December 13th, 2007, 03:10

OpenGL, resolution doesn't matter.

also,
can we get some consistancy with the render modes?

the ShowSpeed should be either Blue in both modes, or Red (which is easier to read on most games) and there should be a way to set where we want it positioned on the screen. (incase it overlaps other games)

mudlord

December 24th, 2007, 08:03

Yes, we can get consistancy. Might need to work more on these.

Also, new SVN build will be uploaded today. Includes:

* No longer requires GLEW32.DLL
* Supports video compression (no support for YUV yet)
* Buffer selection in OpenAL audio driver
* GLSL shaders should support samplers now, as well as a uniform constant for monochrome colours
* Now sound pauses when moving window properly
* Improved DirectSound output driver
* Improved debugging build speed by 20%
* Optimized texture copying

..and loads other updates which I forgot.

Merry Christmas everyone!

Spacy

December 24th, 2007, 11:44

Further info:

- Recorded AVI misses something that keeps audio/video in sync when playing it back in a media player, so when I create CPU load while playing back, A/V gets async. Maybe the old Video for Windows API is just bad?

- Missing support for YUV output to video encoder results in some codecs not working (DivX, MS MPEG, ...). However, ffdshow works perfectly fine, because it supports RGB16/24 input.

- When VBA runs in 16bit mode, AVIs will be recorded in 16bit colors which reduces the size of uncompressed video streams. Of course the best way would be to let the user chose, the only advantage is that it reduces CPU overhead when recording in 16bit.

- New sound pauses have been added, but when the user clicks the MainWindow non-client area, sound will still get asynchronous because I have not found a way to handle this window message. Maybe MFC is bad?

- Texture copying (for D3D & DDraw) was not really optimized, I just found out that the current (my old) assembler code was as fast as the pure C code, so I just deleted the assembler and rewrote the routines a bit. Well, maybe I got a little speed improvement, but nothing major.