Opensnes

[Hanz™]

So my list of things to do are:-

convert ASM cpu core to ADS compatibile format
Add pocketSPC
Ensure sound is crystal clear.
Speed up rendering routines ( if possible )

That should be it.

​

this sounds allway so easy but i know it issn't i hope you get it as fast as possible

good luck

​

Yeah good luck. Quite a task.

 

[GA01]

Reesy

Would it be possible to make BLU+ compatible? When I load Snes.fxe, I'm getting the common white bar. Great to hear your working on this and looking forward to future updates.

 

[Quiest]

Woohoo, the next few weeks a new and better version?
This is awesome news!

Again, the gp32 is alive as never before


Edit: Typos...

 

[MaRcMa99]

good luck you're a master

 

[Tobriand]

Sounds most gloriously cool!

One of the big issues with OS9x was always that, due to Yoyo's weird compiler config no-one could ever get the source to work - essentially rendering the program a bit like a bulletproof window. Source was clearly visible, but you couldn't do anything with it (and thus the whole this was in effect closed). Or so it seemed, at least.

Its awesome that you've managed to get it compiling properly on another system (Ok, without the ASM core as yet, but hey, it'll come, I'm sure). Maybe now it'll be open-open as opposed to open-but-unusable .

The GP32 scene always seems to go through these coding waves... a month will go by where there's nothing at all that happens, and then suddenly, 15 competitions happen at once and a thousand projects no-one had heard of turn up out of nowhere. And so it continues!

 

[Reesy]

Wait a minute Reesy... did you say ADS? A rusty cog in my brain just reluctantly clicked over one tooth and made me remember something.

Didn't you once say that FluBBa's emus all used ADS? You also said that because they did you couldn't use any of his code.

But now that you can use this does this "ADS" mean that some of his GBA emus like the PC-engine, NES etc could be ported to the Gp32? All of the source code for FluBBa's emus and CPU cores are feely available too.... Interesting no?

​

Well we've always been able to use ADS, the Gamepark SDK for ADS has been around for years. Its just a lot of work, Flubba's emulators are very complicated and its not very easy to unpick the GBA hardware related code. Its not just like picking up a PC based emulator and porting it, there is just a lot more work to do. Plus the fact that I have no interest in PC-engine, Nes or GB emulation, means I'll probably never attempt it.

 

[Magus 86]

Reesy's working on OSNES9X... AWESOME. I remember asking him about working on it a few months ago after trying out DrMD, and I was told to do it myself, which I would gladly do if I knew anything about coding. However, he's working on it now, so all is well.

 

[G189]

Reesy - I've got a 20 quid note with your name on it if you can enable my BLU+ to play Super Mario Kart.

 

[diablo2]

wasn't osnes built with ads
why is it hard to compile?

 

[Reesy]

For some reason in version 3.0 there is no ADS project file and for people like me that do not have a clue how to work ADS this is a pain in the ass. There is also alot of assembler code that is included in the project and called from various places but will not compile because it is not in ADS format. I have no idea how idea how YoyoFr go this assembler code to compile before but I'd be interested to find out.

 

[Reesy]

Reesy

Would it be possible to make BLU+ compatible? When I load Snes.fxe, I'm getting the common white bar. Great to hear your working on this and looking forward to future updates.

​

I've just spotted the problem so this should be fixed in the next release. I had assumed that the code was using Gameparks LCD functions because its makes use of the SDK functions else where but it actually uses a Mr.Spiv graphics function. This is why its not compatibile with the BLU+, I'll have to add another menu option which allows you to select the LCD type.

I've also just got the ASM cpu core in as well. It appears that ADS will quite happily load an object file created by GNU. I noticed a few minutes ago that YoyoFr had a Makefile in the assembler directory, so it got me thinking that maybe he just included the object files rather than source and what do you know it works

Reesy

P.S As an added extra this will mean that the split screen bug will be fixed

 

[shinneri]

It may be dumb (I'm not sure if it is or not), but I'm just going to throw this question out, Reesy. Do you think you can get transparencies working (at a reasonable speed)?

This is a question for Reesy as he's the one working on it, so he's the one that would know.

 

[Reesy]

I have no idea at the moment. Optimising the rendering routines is last on my last, I'm going to update the sound core first as this is easier to upate because its just a case of ripping out the old sound core and sticking in the new supa doopa PocketSPC core.

 

[DaveC]

I have no idea at the moment. Optimising the rendering routines is last on my last, I'm going to update the sound core first as this is easier to upate because its just a case of ripping out the old sound core and sticking in the new supa doopa PocketSPC core.

​

Cool. How about the intensity bit thing. If you notice on the BLU when you load a game the game screen area shows as grey instead of the proper black.

That should be an easy fix right?

Thanks much again for the great work

 

[Goity]

how about that transparency simulation thing that davec was talking about once?

 

[Reesy]

Yes I'll bear in mind the interlace transparency effect that DaveC mentioned if I ever tackle the transparency issues in the rendering routines but to be honest I'm not interested in compatibility.

If I spend any time on the rendering routines I will write them to be as fast as possible, even if this means lower comptibility. The GP32 does not have enough power to emulate all the bells and whistle so we may as well have an emulator that runs fast, or at least as fast as possible instead.

 

[Goity]

Yes I'll bear in mind the interlace transparency effect that DaveC mentioned if I ever tackle the transparency issues in the rendering routines but to be honest I'm not interested in compatibility.

If I spend any time on the rendering routines I will write them to be as fast as possible, even if this means lower comptibility. The GP32 does not have enough power to emulate all the bells and whistle so we may as well have an emulator that runs fast, or at least as fast as possible instead.

​

I mean the thingy where is shows a pixel of one layer, a pixel of another then a pixel of another.

read from here: http://www.gp32x.de/board/index.php?showt...ndpost&p=267234

 

[Deserthamster]

Reesy,

I, like may others are excited at the news that you are working your magic on Opensnes for gp32_console .

Can you give us an idea what kind of speed improvements (if any),we can expect to see from future versions of Opensnes ?

It would be a great achievement if most game were playable(with sound) on a gp32_console @166.

Good Luck

 

[Reesy]

Well the current spc emulator is very slow, so I guess that adding pocketSPC will allow games to be alot more playable with the sound on.

 

[Deserthamster]

Well the current spc emulator is very slow, so I guess that adding pocketSPC will allow games to be alot more playable with the sound on.

​

Gr8 news !

How easy/difficult will it be to add PocketSPC sound emulation to Opensnes ?