When will the next version be finally released?

[DSN9990]

@JHRobotics Where are you anyway? I'm very anxious to see the next release of softgpu!

[DSN9990]

@JHRobotics I'd love to see you again, so please reply to me. Thanks!

[DSN9990]

I noticed that the current version of SoftGPU is so bad... Almost no game I tested worked so far...

[DSN9990]

@JHRobotics What happened to you?

[hughobrien]

Please. Stop.

[DSN9990]

OK, but what happened to JHRobotics anyway?

[NS-Clone]

but yep this time there is to long silence from JHRobotics
only few commits over half year

[DSN9990]

Anyway, sorry for that, I just want to know when a new version will be released. I apologize for that.

[JHRobotics]

Sorry for long silence, this is caused by requirement of rewrite quite important parts of driver + directx/direct draw HAL. I thought I will be much faster and have more time to do it :-(

There are these 5 things that needs be done:

1. VRAM management: old Windows and old DX using video ram like any ram memory, usually map in linear memory space (this is why unpatched Windows 9x crash when connect GPU with 512 and more MB VRAM). This is clearly visible in VESA driver, where some operations – like scroll down incredible slow (practically read part of VRAM and write to VRAM a little further). Solution is emulation VRAM completely with RAM and only some operation writes only to real VRAM. Unfortunately, Win9x are very fragile when allocating huge memory especially large continuous block.
2. Grouping screen changes: on RAM to VRAM copy is ineffective to copy individual bytes especially on larger frequency then display frequency. Solution looks easily – sets the timer and write all change when it rings. But… there is some kind of race condition or another bug and driver sometimes freeze when time event occurred.
3. Surface management: DirectX until version 8 directly accessing VRAM and writing and reading texture memory by CPU – except for the problem mentioned in 1) I need trace this memory and notificate changes to Mesa3D these changes could be also from different threads or from different process. Extreme important is garbage management because usable memory is not very much.
4. SMP (Symmetric Multiprocessing): Mesa3D burns relatively lots of CPU, so main idea was utilizing other CPUs (Win9x normally only support 1 CPU). So, I created this: smp.vxd. Good news it that it works, bad news that performance boost isn’t still very significant.
5. VirGL: VMware base HW acceleration isn’t very fast and was designed to desktop acceleration not for 3D applications (like games). I started work on VirGL, but progress is slow – documentation is missing, QEMU support for Windows is not great and support for Win9X as guest is much worse = there is very slow I/O emulation for legacy SW. In fact, perfect state is implemented VirGL under SoftGPU (vmdisp9x+mesa9x) and implement it to VirtualBox – it could be possible but is very long way to go.

Please be patient, currently points from 1-4 it is on good way, and some new releases could be in this summer.