retroemu.com winter code contest

Been thinking about joining and participating in this.
http://www.retroemu.com/showthread.php?p=687#post687

Just think about it: tracked music, small game size, 2 player support, fancy VFX....
No chance of a Mac port, even though I will be using BASS and OpenGL, which do work on Macs. I know it will not be the caliber of Plasma Pong, which was in devel for around 9 months, but fuck it. I WILL have fun developing this.

Hooray!

Finally a public response:
http://moogle-tech.com/blog/?p=85

EDIT: All sorted. No drama here, everything peachy :).

What is needed.

I have been thinking and something is sorely missing from the N64 emulation scene, a video plugin which:

* Is developed on a consensus (games MUST be tested from start to finish, AND be faithfully emulated. That is, if a effort to emulate SM64 is done, it MUST be done from start to finish and the end result should look like real hardware)
* Uses NO inis for configuration, except for storing things like screen resolution. This means, no per game hacks in a game INI.
* Is developed for emulation in mind (NO texture packs)
* Has support for hw accelerated filters (eg. 2xSai on the GPU)
* Supports clean ROMs ONLY (no hacks, just (U) or (J) ROMs. Only supports PAL in circumstances that warrants it).
* Can be ported to Linux and MacOSX

Must be batshit crazy, whatever. Just some things I have been thinking about.

DX10, Crysis and you.

Greetings all.

Its been ages since I discussed about graphics rendering, since I no longer frequent boards in which this is a topic (namely Ngemu.com). Mainly due to me losing interest in the whole emulation development scene, due to some reasons.

I have been however, watching over it, to see how things unfold. However, I have seen several misconceptions about DX10, DX9, and OpenGL.

One of them, is godrays under DX10. That, is a complete and utter misconception. It is possible to render raymarched underwater godrays in DX9, and hence, OpenGL 2.0:As shown in the screenshot from "Just Cause", a PC/Xbox360 title, underwater raymarched godrays, along with depth of field are easily rendered in DX9 and therefore OpenGL 2.0. Not to mention: soft shadows, parallax mapping, depth of field, refracting water, a
model of light scattering and absorption for underwater rendering, caustics, and SSAO are easily done under DX9. Hence in Crysis, is there really a need for the DX10 renderer?

To be honest though, the only real benefit DX10 should offer is improved instancing (for more speed) & more flexible shader operations under Crysis, since its plainly obvious, all the effects can be done under DX9. However, with OpenGL getting improvements, whats the point in making a API Vista only? Plus, if you work hard enough, shader model 3.0 shaders should be fine, along with procedural code on the CPU.

So basically, imho, DX10 under Crysis offers basically nothing. Considering that performance in tests has even shown to decrease in DX10 mode, shows really, why the need for it? Seems all marketing spiel to me.

So in that case, DX1o does not rule. It indeed sux, because it doesn't exploit it well. I have to admit though, if the implementation is done right, DX10 rendering can be quite good.

I quit the emuscene

Here, I declare my reluctance to take part in the GBA/N64 emu scene.

This means that MuNES, which was a project done for the retroemu.com coding contest, will also cease development after its final rls.

So long to those who are good in the scene and fuckings to the people who deserve no respect.

Could be two months, two years, two decades, enough is enough.

Bye.

Speed or code clarity....?

Recently, I had a major dispute with one of my accomplices. I'm not at all going to sugar coat it - it was byuu, of BSNES fame, funnily enough.
Its quite funny how it started, then it turned immature...And guess what it is about: Code clarity or speed optimization. And code optimization is something I hold close to my heart.

Now, to understand the problem of this argument, you must first understand the differences in idealogy to each approach. Code clarity is about keeping code nice and simple, and easy to read. Code optimization is about trying to fit the same amount of work in less space, which means, less work for the CPU to do. We are talking about this in a emulation sense. And since both byuu and I believe speed hacks are the spawn of Satan, we are not, I repeat, NOT referring to anything that hinders accuracy.

Now then, there are several reasons why I prefer code optimization:
* Speed (well, duh) &
* Minimization or eradication of bloat, and not contributing to the "bloatware" problem in the IT society.

Now then, I have seen all too often how software over time has become more and more bloated. (a famous computer scientist noticed this pattern as early as 1995) And here is where one of the idealogies of byuu's and I's collide. I personally feel that we should make a effort to write code that is efficient and of as little bloat as possible. These days, we see operating systems, such as Windows Vista, and various PC games, taking up more CPU power, RAM, and HD space, than is really deemed worthy. By writing software that takes a non optimized approach, we are contributing to this problem, and make it more acceptable to make unefficient software. Which to me personally, is not. Add on top of that the ever more increasing advances in technologies and developers, can be sucked into not optimizing thier code, since, recent hardware can handle this. I personally find this utterly appauling. As developers, code should still be optimized. Not optimizing or taking little effort, to me, is a sin. Not to mention, even though I have 5-10 year hardware around that is still usable, I want my programs to run well on them. I hardly think then, relevance is even a good excuse to not optimize, as not optimizing, is just contributing to the bloatware issue.

Now, speed. To most people, speed is important. To me it is too. Having something optimized for speed, can certainly help with testing, as there is a wider possible user base. Which can be benificial in case. Not catering to a full crowd is quite underhanded, not to mention not nice. So speed optimization, to me is a important factor in how I code.

And as for code clarity when optimizing, there is such a thing as code commenting. I would have thought code commenting would have been a staple in documentation. So, I don't see how code optimization can be a issue, unless you are using really arcane optimizations to get a extra 10FPS. But still, you can comment on those optimizations explaining how they work.

So in conclusion my views are:
* Optimization should matter, not be a elective.
* Relevance is not really warranted. Code optimization code should be done, regardless of target hardware
* There is nothing wrong with commenting code
* We should not contribute to Wirth's law.

Bye.

Game_Music_Emu plugin for Winamp 5

Hi folks,

I started to port my player app to a Winamp plugin. Which focuses on GME support. For those that dunno, read earlier.

Here's the link: http://vba-m.ngemu.com/personalpage/downloads/in_gme.zip