VBA-S [S as in Spacy]

[Squall-Leonhart]

yeah, i already have the Feb Redist, which has all the files, that one was missing for some reason... odd.

reinstalling fixed it

[Spacy]

Originally Posted by warstoke

ive been having another small problem with it forgetting the controler config i use a usb game pad and almost every time i start it up i have to reconfigure it.
on the issue with the directx dlls
http://www.threelights.de/index.php?..._dll_files.php
has them all in 1 installer

Hi. I jsut tried that game pad bug out. [Logitech RumblePad 2].
Everythign works fine if you keep your game pad plugged. But if you disconnect it and start VBA, VBA will automaticly reset the devices's configuration because it can not find the correspondant device.

Maybe it would be better to just ignore the [at this moment] wrong settings and keep the button config, so it will still be usable when you reconnect your game pad and start VBA.

I will definitely have alook at it as soon as I have more spare time from school.

[warstoke]

well i dont unplug my controller but it could have something to do with it being a peice of junk Gamer's Factory usb controller the company isnt even around any more lol but dang if sam goodies dosnt have about 10 of each of their products

[Spacy]

Hi guys. Lately I have been dealing a bit with wxWidgets. wxWidgets is comparable to Microsoft's MFC, but it is platform independant and easier to develop (imo). I am really thinking of rewriting the VBA GUI to use wxWidgets, because I could make the whole code look cleaner and make it easier for new developers to add things. Moreover it should not be too hard to use the normal VBA emulation cores (GB/GBA), because they are coded GUI-independant. So, what do you think? For me it would be a great incentive to create something on my own, and besides, I could get deeper into platform-independant development. Afaik, VBA could then be easily ported to Mac, Linux and maybe even to embeded devices if the wxWidgets developers work on that.

[Squall-Leonhart]

if its easier to work on in the future then sure, its a good idea, that will mean it will be easier to add features and fix bugs etc wouldn't it?

[Forgotten]

I remember looking at wxWidgets, but it didn't seem like it would perform well. If you ever used the GTK version of VBA, you proably know that it is kinda of slow. Nothing really beats DirectDraw/OpenGL/Direct3D on Windows at least or SDL on the other systems.

If you can make wxWidgets and SDL work together or if they really have a direct buffer input, you might have a chance of having reasonable performance.

[Squall-Leonhart]

hmm.. well the current performance of this version of the emulator isn't to good.. so maybe its best to sort out that first?

[suanyuan]

Originally Posted by Spacy

Hi guys. Lately I have been dealing a bit with wxWidgets. wxWidgets is comparable to Microsoft's MFC, but it is platform independant and easier to develop (imo). I am really thinking of rewriting the VBA GUI to use wxWidgets, because I could make the whole code look cleaner and make it easier for new developers to add things. Moreover it should not be too hard to use the normal VBA emulation cores (GB/GBA), because they are coded GUI-independant. So, what do you think? For me it would be a great incentive to create something on my own, and besides, I could get deeper into platform-independant development. Afaik, VBA could then be easily ported to Mac, Linux and maybe even to embeded devices if the wxWidgets developers work on that.

The other idea is to seprate the GUI from emulation core as a stand alone front end.

Let GUI front end handles GUI stuff then pass the setting information to VBA core by setting file or setting xml or even with command line parameters.

The greatest emulator MAME works very well by this way.

[Forgotten]

Someone is more than welcome to find a way to improve performance. If you want correct emulation, that's what PokemonHacker did. If you don't mind bugs, just use version 1.7.2 but not everything will work.

[JKKDARK]

which things does not works???

[Spacy]

@Forgotten:
IMO, game compatibility goes first. We can not enjoy fast emulation if the game actually is not playable because of bugs.

Well, on the other hand, we can not play games at 50% speed, but I guess this is only a problem on older CPUs.

[Squall-Leonhart]

my cpu is a 2000+ @ 1667mhz.

1.7.2 worked fine on my Duron1100, this version barely runs on it. and its using the exact same settings and looks exactly the same.

[Cyberfreak]

You know that you should make it so it supports gameshark sp cause thats the one that is supported on there web site. They don't support the old gba one anymore.

[Squall-Leonhart]

thats a good idea... improving the way the cheat box looks as well as descriptive info would be awesome.. i always used to put the code in the wrong part and have to enter it again.

[Cyberfreak]

The cheat box should be able to connect to the cheat web sites for easy access to cheat.

For exp the softwear that comes with most cheat devices makes it so you can easly load cheats from the web site to the softwear and be able to transfer it to your cheat device though the cable link.

You kinda get what I am saying it would make it easyer to transfer codes from the web site to the cheat device meaning no endless time typing or copy or paste codes into the cheat box.

[Squall-Leonhart]

no i don't agree.. that would actually make it more likely that a random virus could be downloaded.

but, someone should create a database that contains all the cheats, sort of like PJ64 has.

[Spacy]

Since pokemonhacker seems to be offline for a while (does anyone know what's going on with him?), I changed my plans a bit. I will continue to release WIP versions until someone fixes the 1.8 core, because I do not want to release a buggy version

Regarding the issue with new game shark codes:
I could have a look at adding the new code format, but only if someone can give me some informations about the new format.

Online cheat database: too much work (just for cheating o.o")

wxWidgets: I changed my opinion, it is better to get the MFC thing stable, then I will care about other platforms.

By the way, I am selling my second PC just to get money to buy me a new one (some people need cars, I need computers ). The new thing will definitely use an AMD (anagram: MAD xD) Athlon 64 or Opteron with at least 1MB L2 Cache. Moreover it will have PCI-Express and be extremely silent. (Just what a developer needs ). But don't worry, I won't ask for money here, although it would be a nice imagination.


And finaly, the files, a nice backup if my computer breaks occasionally (this word is as hard to spell as miscalleneous )

Change Log:

S1.7.7 WIP (Visual Studio 2005):
- Migrated project and code to Visual Studio 2005
    - needed to make some code stricter
    - native manifest integration
- Added speed configuration table
- Added flash size option to emu tab
- Fixed: Window size was reset after closing the options dialog
- Fixed: speedupToggle will now be saved
- Removed several setting menus
- Code cleanup
- Minor issues

The exe is built with SSE(1) support, so your CPU must support this, but about every CPU since about 1999 supports it. I will not lose a word about MMX

Here's the All-In-One package: (1,77MB)
http://mitglied.lycos.de/spacy51/vba..._2006_04_14.7z

[tomotachi]

final fantasy 4 advence is lagging ...... fix again

[RockmanForte]

Good job! I know it have more bugs but good job. Keep up the good works. This emulator need to continously update.

Keep up!

[Squall-Leonhart]

..feels slower ...