Any New Developments?

[Macintosh User]

Haven't heard anything in a while... just wondering if any new releases were on the way?

[Shamus]

Yes, 1.0.7 is on the way, I just need to hear from Niels before I can tag CVS and do a release.

Niels: Where are you?

[Macintosh User]

Very cool. I hope everything is starting to come together nicely for you. Your team has done an excellent job. I am very impressed with the Mac OS X version of VJ. Hopefully version 1.0.7 will be even better than 1.0.6, and it sounds like 1.0.8 is gonna be the best release yet. What with the few little extra surprises you hinted at in another thread. My only question now is how to configure a controller correctly for VJ. Maybe in future releases you could make it an option in the GUI... thanks again for responding to my inquiry. I can always test out betas for you on OS X if needed. I run 10.2.8 (Jaguar OS X) and am planning on upgrading to Tiger, OS 10.4 as soon as it launches in the near future. So I'll have the most up to date operating system Macs can use.

[nwagenaar]

Originally Posted by Shamus

Yes, 1.0.7 is on the way, I just need to hear from Niels before I can tag CVS and do a release.

Niels: Where are you?

At the moment I'm in the Netherlands. After cellibrating I deserved a good vacation so I was somewhere in Europe enjoying sun, beer and beaches :P So that will come up in the next couple of weeks.

In short, you can release the new version (I'm working on the Linux based CD emulation) but release it as a public beta version since I would like to know how CD emulation performs by others I have some issues with the WIN32 version but this could be because of my JaguarCD backups (if somebody could donate original JaguarCD's, please do since they are hard to come by, even on Ebay!).

Oh yes, time is very short for me since I now have 60 hour workdays and I've got to work in the weekends to But this should be resolved after my vacation (2nd through 22nd of August).

Regards,

Niels Wagenaar

[nwagenaar]

Allright,

Time for me to do a post again (I've lost the url of the CMS on the website and I'm to lazy to find out) concerning Virtual Jaguar development.

At the moment I'm focussing on a rewrite of the graphics handling within Virtual Jaguar (in fact the sdlemu librarty parts). I'll focus namely on the standard SDL scaling/stretch and the OpenGL source. I've worked out some OpenGL specific en stretching/scaling optimisations and I think I can make this work within the current sourcebase.

Why you may ask. Well, this code is roughly 1.5 years old and it's buggered as hell. It's definately not clean and not documented correctly within the source. Hopefully, the sources will be compatible so that a simple recompile should do the trick. Don't worry, we won't commit anything to CVS as long as it breaks things up

Also, the JaguarCD code for UN*X is on hold atm. I do think it's possible to make use of generic cd-rom code instead of the platform specific code but the truth is, I never tried or developed with the sdl cdrom based interface. So maybe Shamus can enlighten me on this topic

Regards,

Niels Wagenaar

[Shamus]

I'm looking forward to the new OpenGL enhancements.

As far as using SDL for CD, it can't be done--certainly not in its current state. We need to be able to read raw sectors from the CD and SDL doesn't offer that. I know--I looked long and hard it before coming to the conclusion that we'd need platform specific back-ends for the CD code.

The only thing that SDL supports as far as CD goes is playback and high level control functions like pausing and track skipping... Now if SDL supported low level CD access, then I'd be all for it, but, sadly, they don't. And I doubt that they'll add support for it since there isn't much need for low level CD access.

Other than that, I think we need to release 1.0.7 ASAP just to get the filesystem/config file bugs that are in 1.0.6 out of our hair. We can then use 1.0.8 to fix stuff like CD support... Of course we can wait until you put your OpenGL fixes in, if you'd like. Either way, though, I think we need to do a release and soon (even if only just to get people to start using the .J64 extension on their uncompressed ROMs ).

[nwagenaar]

Originally Posted by Shamus

I'm looking forward to the new OpenGL enhancements.

As far as using SDL for CD, it can't be done--certainly not in its current state. We need to be able to read raw sectors from the CD and SDL doesn't offer that. I know--I looked long and hard it before coming to the conclusion that we'd need platform specific back-ends for the CD code.

The only thing that SDL supports as far as CD goes is playback and high level control functions like pausing and track skipping... Now if SDL supported low level CD access, then I'd be all for it, but, sadly, they don't. And I doubt that they'll add support for it since there isn't much need for low level CD access.

Other than that, I think we need to release 1.0.7 ASAP just to get the filesystem/config file bugs that are in 1.0.6 out of our hair. We can then use 1.0.8 to fix stuff like CD support... Of course we can wait until you put your OpenGL fixes in, if you'd like. Either way, though, I think we need to do a release and soon (even if only just to get people to start using the .J64 extension on their uncompressed ROMs ).

Ah, now I know what the reason was. The raw sector reading issue. Only, the problem is that the UN*X specified code can only be tested on Linux. I don't know how it will perform on for instance MacOS X (which has a MACH/BSD kernel). In the past I used platform specific soundcode for BoyCott Advance and it was a real nightmare to get the sound running on other UN*X-oid systems. I think this problem will also be the case on CD-ROM based functions within Linux, FreeBSD, etc. So I'm looking into this after I get the new graphics code done.

Concerning the release, release it when you can. I need to rewrite the graphics code first (I'm still testing some code and then I'll incorperate it within the sdlemu stuff) and this won't be done over a weekend or so. I hope that the new scaling/stretching code is much more flexible and can be used with all related projects. I'm working out some idea's but the truth is, I don't know how to begin. The code is about 1.5 years old and some idea's are missing (braincells gone because of beer) why I did that. But I'm possitive I'll bring something out to test in a short while.

Regards,

Niels Wagenaar

PS : Please look at your stars. A little gift I promised ages ago :P

[Shamus]

Ah, stars. Cool.

I'll tag CVS as soon as I can and put an announcement on icculus. One thing that would be very useful would be the ability to stretch different parts of the screen independently, so that, say, the top half of the screen could have twice the horizontal resolution as the bottom. I'm not sure what the overhead would be (especially if it could be done on a per scanline basis), but it would be a nice thing to have. Even if you could only do 2 different horizontal stretches at the same time.

[nwagenaar]

Originally Posted by Shamus

Ah, stars. Cool.

I'll tag CVS as soon as I can and put an announcement on icculus. One thing that would be very useful would be the ability to stretch different parts of the screen independently, so that, say, the top half of the screen could have twice the horizontal resolution as the bottom. I'm not sure what the overhead would be (especially if it could be done on a per scanline basis), but it would be a nice thing to have. Even if you could only do 2 different horizontal stretches at the same time.

LOL @ remark stars

Before I begin with babbling about scaling or OpenGL, I've been looking in the latest code I could found on my harddrive (being VJ/SDL v1.0.6) and it really shocked me. Did I write this? (since the SDL graphics is almost my handy work I think so) In that case I apoligize and I hope to write a more understanding version what people can use and exploit.

Concerning the scaling. Ofcourse I can write scaling based upon horizontal or vertical base or a mix. The overhead is twice less then when using complete scaling and it's infact a copy of the exact scaling code, only it's directed to X or Y instead of X and Y.

OpenGL is a different mather. The inialisation code (in sdlemu_opengl.c and video.cpp) is infact incorrect and I know the problem why OpenGL is slower then normal SDL blitting:

1. The use of an ackward resolution (instead of 320x240, 640x480, etc);
2. The conversion from a 16bpp surface to a 32bpp (<- SLOW!);
3. OpenGL initialisation items that aren't done.

For VJ (or other projects as well) 1 is not a problem. In fact, this solves the problem when the switch/expension of width and height are made when you use a resolution of for instance 640x480. The textures are smaller then the resolution and will "automaticly" scale to the new resolution ( so your OpenGL hack isn't needed any more). 3 is also not a problem, some simple initialisation are not used or are incorrect. This can easily be fixed.

2, well this is the main problem. The conversion from 16bpp (surface, our renderbuffer) to 32bpp ( src, our OpenGL texture) and then render it to our 16bpp screen ( mainsurface, our main SDL_Display ) takes up most of the time (also mainly because of some missing initalisations) and this has got to be fixed/rewritten. How this will be done, I do not know yet but I have some idea's. And I'll consult the SDL library mailinglist for some pointers.

Shamus, when you've released the source to the public, could you please send it to me ( shalafi.nospam [AT] xs4all [DOT] nl ) so I can work with the latest codebase? I've kinda lost my login information from icculus :/

Regards,

Niels Wagenaar

[nwagenaar]

And to let you all know. Virtual Jaguar/SDL v1.0.7 is now available to the public Check the main site or the upcomming thread.

Regards,

Niels Wagenaar

[thor_the_viking]

@ Macintosh User

Hi,

just downloaded VJ for Mac OS X, but I am not able to use. Can you give me a short "How to.." description please.

Cheers

th