Developer's wanted

[denopqrihg]

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]

Originally Posted by VisualBoyAdvance Homepage
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]

Originally Posted by denopqrihg

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 )

Rewriting some of the code code into assembler is going to be awesome!

I can't wait to see the next build!

[ODECiF]

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

__________________
Pc Specs:
Processor: <----> Pentium3 [1.8GHz]
Graphic Card: <-> nVidia GeForce3 Ti200 [64MB]
RAM: <----------> 512 MB
CD/DVD: <------> COMPAQ DVD-ROM DGR8160B/ LITE-ON LTR.24102B/ [DAEMON]
HDD: <----------> 40GB + 180GB at NAS-server
- II -:
Processor: <----> Pentium4 [2.4GHZ]
Graphic Card: <-> ATi RADEON 9500 PRO / 9700 Family [128MB]
RAM: <----------> 512 MB
CD/DVD: <------> LITEON DVD-ROM LTD163 / _NEC DVD_RW ND-3540A / [DAEMON]
HDD: <----------> 230GB + 110GB

[Squall-Leonhart]

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

__________________

VBA-M | Xtemu | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.6 | Satanic666's Emulator Compiles
Don't be a NOOB, READ THE NGEmu/EmuForums Rules of Conduct
Need Help with ePSXe? This is your first stop!.
If you don't post all the required information, you don't get help.
Everytime someone posts a romsite, God kills a beautiful woman.

[Exophase]

Originally Posted by denopqrihg

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 )

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.

[Cooguy1212]

Hey Exophase. I didnt know you spent time here?

[Squall-Leonhart]

Originally Posted by Exophase

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?

__________________

VBA-M | Xtemu | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.6 | Satanic666's Emulator Compiles
Don't be a NOOB, READ THE NGEmu/EmuForums Rules of Conduct
Need Help with ePSXe? This is your first stop!.
If you don't post all the required information, you don't get help.
Everytime someone posts a romsite, God kills a beautiful woman.

[Cooguy1212]

Trust me, He is very smart.

[Squall-Leonhart]

not really.

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

__________________

VBA-M | Xtemu | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.6 | Satanic666's Emulator Compiles
Don't be a NOOB, READ THE NGEmu/EmuForums Rules of Conduct
Need Help with ePSXe? This is your first stop!.
If you don't post all the required information, you don't get help.
Everytime someone posts a romsite, God kills a beautiful woman.

[Cooguy1212]

You don't think hes smart?

[Squall-Leonhart]

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.

__________________

VBA-M | Xtemu | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.6 | Satanic666's Emulator Compiles
Don't be a NOOB, READ THE NGEmu/EmuForums Rules of Conduct
Need Help with ePSXe? This is your first stop!.
If you don't post all the required information, you don't get help.
Everytime someone posts a romsite, God kills a beautiful woman.

[Exophase]

Originally Posted by Squall-Leonhart

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]

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

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?


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

__________________

VBA-M | Xtemu | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.6 | Satanic666's Emulator Compiles
Don't be a NOOB, READ THE NGEmu/EmuForums Rules of Conduct
Need Help with ePSXe? This is your first stop!.
If you don't post all the required information, you don't get help.
Everytime someone posts a romsite, God kills a beautiful woman.

[Exophase]

Originally Posted by Squall-Leonhart

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.

Originally Posted by Squall-Leonhart

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

Originally Posted by Squall-Leonhart

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]

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 :/

__________________

VBA-M | Xtemu | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.6 | Satanic666's Emulator Compiles
Don't be a NOOB, READ THE NGEmu/EmuForums Rules of Conduct
Need Help with ePSXe? This is your first stop!.
If you don't post all the required information, you don't get help.
Everytime someone posts a romsite, God kills a beautiful woman.

[enderandrew]

Originally Posted by Exophase

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]

Originally Posted by enderandrew

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.

Originally Posted by enderandrew

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.

Originally Posted by enderandrew

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.

Originally Posted by enderandrew

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]

Originally Posted by Exophase

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)

__________________

May the fleas of 1000 camels infest the crotches of BIOS swappers! And may their arms be too short to scratch!

My deviantART | My Blog | VBA-M | @ES | PCSX2 | GeneralEmu | XTemu | Webcomics

[plaes]

Is there any work being done on VBA?

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