Dolphin, the GameCube and Wii emulator - Forums

You know, I'd really like to know what the actual post was

Try annoying him via PM, I guess.

It was just a link to his latest blog post: http://www.mudlord.info/blog/?p=51

Not sure why neobrain felt the need to protect us from these truly horrifying images.

I took his post (the "getting off my arse" part) to mean mudlord was (finally?) doing some GB work given the blog post. Perhaps something was lost in the translation, so to speak.

At any rate, work on HD Tile Replacement (HD graphics) has begun! You'd be surprised just how much more difficult it is dealing with 32,000+ colors instead of 4

Yes, was working on some GB/GBA shit. Figured I finally be constructive again, but only for me. End users can go rot.

Quote:At any rate, work on HD Tile Replacement (HD graphics) has begun! You'd be surprised just how much more difficult it is dealing with 32,000+ colors instead of 4

To complicate matters, do so for GBA.

(07-26-2014, 02:01 PM)mudlord Wrote: [ -> ]

Quote:At any rate, work on HD Tile Replacement (HD graphics) has begun! You'd be surprised just how much more difficult it is dealing with 32,000+ colors instead of 4

To complicate matters, do so for GBA.

I actually very much intend to do so, once my GBA emulator matures. As of now, it can only run a handful of ARM instructions, and basically 2 THUMB instructions. Ah, the joys of little free time. Been working most of the week (my real-world job), trying to get more cash, so nothing got done with the ARM CPU emulation.

The theory behind HD Tile Replacement should actually translate well to many other systems, for the most part, but there are still notable gaps that I still haven't figured out yet. I have plenty of possible solutions, but crafting them into elegant solutions and implementing it well is the tricky part. I'll get there though.

Good luck with your GB/GBA work btw.

The main things wrong with my GB stuff atm is accuracy: I don't intend on going per-cycle/mid-scanline accurate due to ethics resulting as such. Plus, Gambatte already exists for that. As it stands, the LCD rendering and GB CPU stuff is well off, basic things like stack handling which should be fixed. Really not too concerned about estoric mapper support though.

As long as the GBA emulation is better than VBA, I would be happy for my stuff.

Yeah, midscanline rendering is not a priority for me either. I'd rather work on "fun" stuff like the GB Printer, Serial Link, and the IR port myself. Only demos and Prehistorik Man make use of midscanline rendering, though apparently it isn't too difficult to setup, at least that's what I got from another dev who implemented it. Still not going to be on my radar any time soon.

What ways are you going to improve your GBA emu over VBA-M? You said it's going to be for.yourself, not end-users, so I imagine a lot of the design choices will be to fit your tastes. Keep us updated, if you don't mind; I'm interested in seeing what you do

The main problems with VBA-M are from what I know:

* Missing ROM prefetch (a biggie, but thats a common problem)
* Timing (just play Mother 3......)
* Code style (its non existant.)
* Missing support for pixel shaders (CPU filters are dead)


GB Printer emulation sounds fun indeed. GB Camera would be even more cool.

Are any of you guys familiar with building Blender? Ive been trying to get the Opensubdiv-modifier branch working, but I cant seem to figure out where to store the files tp be recognized by cmake. Im guessing a few people here are familiar with cmake, so I was wondering if there was a way to dig into the build files that come with blender's source to see where I need to store the OSD files, but so far I haven't had any working result.