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.
Sunday, October 5, 2008
Saturday, October 4, 2008
Hooray!
Finally a public response:
http://moogle-tech.com/blog/?p=85
EDIT: All sorted. No drama here, everything peachy :).
http://moogle-tech.com/blog/?p=85
EDIT: All sorted. No drama here, everything peachy :).
Thursday, October 2, 2008
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.
* 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.
Wednesday, September 24, 2008
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.
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, amodel 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.
Tuesday, September 16, 2008
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.
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.
Tuesday, August 5, 2008
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.
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.
Wednesday, May 14, 2008
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
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
Sunday, March 16, 2008
Glide64 wrapper update
- Made several changes to how the PFD's are handled
- Optimized the extension detection and how the fake window is created.
As usual, at Glide64 forums for download.
- Optimized the extension detection and how the fake window is created.
As usual, at Glide64 forums for download.
Monday, March 3, 2008
Yay!
Here's something that might be interesting to people who want to read up on me:
http://ngemu.com/articles.php?action=view&rid=32
^_^
http://ngemu.com/articles.php?action=view&rid=32
^_^
Sunday, March 2, 2008
Work on Windows music player started
I now started to work on my player:
So far, executable size is only 136KB..Biggest component is GME, followed by BASS, then zlib, then the PNG image shown above, then libv2 and the MIDI synthesiser code.
More pictures will come when I work on it more....
So far, executable size is only 136KB..Biggest component is GME, followed by BASS, then zlib, then the PNG image shown above, then libv2 and the MIDI synthesiser code.
More pictures will come when I work on it more....
Thursday, February 28, 2008
Something...
Okay...
After about a couple of hours messing with MSVC2008, I came up with something:
For the unenlightened, its a music player based on blargg's Game_Music_Emu. With his patches for cycle accurate emulation. It supports every single format his player support, and it doesn't support DirectSound. I instead used only WaveOut, and so it took a bit of research to do and plug it into a simple libao interface. Not bad huh?
Its available by request. And I am planning a Windows GUI version..too.
After about a couple of hours messing with MSVC2008, I came up with something:
For the unenlightened, its a music player based on blargg's Game_Music_Emu. With his patches for cycle accurate emulation. It supports every single format his player support, and it doesn't support DirectSound. I instead used only WaveOut, and so it took a bit of research to do and plug it into a simple libao interface. Not bad huh?
Its available by request. And I am planning a Windows GUI version..too.
Thursday, February 21, 2008
MAME...Ugh...
This is my first real rant on here.
Its against one of my major pet peeves. MAME
Now, before MAME fanbois come in to flame me to death about my views, here them 1st.
Okay lets start this rantfest.
1) Developer Attitudes: This is by far the largest pet peeve I have. Before people quote me from the MAME licence. I would like to highlight a previous exchange with someone affiliated with Mamedev in the past. This particular person labelled emulation enthusiasts "ROM kiddiez", soley for using emulators that are different from MAME's cycle accurate approach. Now, this really pisses me off, as it shows the extreme arrogance and disrespect people have. If they didn't have this attitude, I wouldn't be so pissed! And this, is one of the biggest problems with the scene today. In that, there's the whole "accuracy versus speed" debate. Why don't people respect ALL approaches of emulation, rather than be close-minded kooks and cling to thier ways. Afterall, shouldn't we have unity on this planet?
2) Bloat: For instance, the MAME executable weighs in at around 7-20MB. Thats insane, and its a pain in the arse for dial-up users.
3) There is no individual emulators: This means that dedicated emulation is out of the question. Which plainly sucks ass. Two perfect examples of how good dedicated emulation can be is Nestopia and BSNES. No need to continue there. On top of that, you are bound to MAME's code standards and systems. Which again, sucks ass, as there goes flexibility. And all for the sake of cycle and sub cycle accuracy. Way to go....
4) The idiocy with licensing: MAME has a extremely restrictive license. Which stifles innovation. And instead, focuses development on the dogmatic and narrow minded will documenting hardware. Whereas, emulation could be so much more.
5) User friendliness: Need I say more? It looks quite absurd, not to mention, its handling of required BIOSes is utterly terrible....Can go on about SNES emulation with this thing, when with MESS...
6) Game lists: This locks out support for unknown titles. If it is truly a documentation project of hardware, these would be unneeded and irrelevant. Thus, this locks the emulator into ONLY supporting games that MAMEdev desires to be supported. Which is quite idiotic IMO.
7) Lack of modularity: If things were modular, size would be less of a issue. But due to the insistence of locking into specific release builds, size will always be a issue.
Thats enough for now....
Have fun....
Its against one of my major pet peeves. MAME
Now, before MAME fanbois come in to flame me to death about my views, here them 1st.
Okay lets start this rantfest.
1) Developer Attitudes: This is by far the largest pet peeve I have. Before people quote me from the MAME licence. I would like to highlight a previous exchange with someone affiliated with Mamedev in the past. This particular person labelled emulation enthusiasts "ROM kiddiez", soley for using emulators that are different from MAME's cycle accurate approach. Now, this really pisses me off, as it shows the extreme arrogance and disrespect people have. If they didn't have this attitude, I wouldn't be so pissed! And this, is one of the biggest problems with the scene today. In that, there's the whole "accuracy versus speed" debate. Why don't people respect ALL approaches of emulation, rather than be close-minded kooks and cling to thier ways. Afterall, shouldn't we have unity on this planet?
2) Bloat: For instance, the MAME executable weighs in at around 7-20MB. Thats insane, and its a pain in the arse for dial-up users.
3) There is no individual emulators: This means that dedicated emulation is out of the question. Which plainly sucks ass. Two perfect examples of how good dedicated emulation can be is Nestopia and BSNES. No need to continue there. On top of that, you are bound to MAME's code standards and systems. Which again, sucks ass, as there goes flexibility. And all for the sake of cycle and sub cycle accuracy. Way to go....
4) The idiocy with licensing: MAME has a extremely restrictive license. Which stifles innovation. And instead, focuses development on the dogmatic and narrow minded will documenting hardware. Whereas, emulation could be so much more.
5) User friendliness: Need I say more? It looks quite absurd, not to mention, its handling of required BIOSes is utterly terrible....Can go on about SNES emulation with this thing, when with MESS...
6) Game lists: This locks out support for unknown titles. If it is truly a documentation project of hardware, these would be unneeded and irrelevant. Thus, this locks the emulator into ONLY supporting games that MAMEdev desires to be supported. Which is quite idiotic IMO.
7) Lack of modularity: If things were modular, size would be less of a issue. But due to the insistence of locking into specific release builds, size will always be a issue.
Thats enough for now....
Have fun....
Monday, February 18, 2008
Some notes..
1) Source code for NDS FE is there for people to tinker. Basically, its finished, bugs need to be fixed. I am currently too busy with more important things than work on it at this point in time.
2) New VBA-M update. Has more optimizations to the core. Please try it.
3) University has began again. So my spare time has went down a bit. Please keep this in mind when asking about release dates, and this is why things are released when its done. I can't stress that point enough. Plus, I generally do things when I feel like it. So don't pester me for things, as I wouldnt listen.
4) Don't ask for ROMS. Please...
2) New VBA-M update. Has more optimizations to the core. Please try it.
3) University has began again. So my spare time has went down a bit. Please keep this in mind when asking about release dates, and this is why things are released when its done. I can't stress that point enough. Plus, I generally do things when I feel like it. So don't pester me for things, as I wouldnt listen.
4) Don't ask for ROMS. Please...
Tuesday, February 12, 2008
VBA-M and Qt
I managed to get stuck into rewriting the main options dialog of VBA-M.
Oh you don't know what VBA-M is? Well, it is a project aimed of taking all the good bits out of every VBA fork, and sticking them in one, thus, end users no longer have to stuff around with heaps of useless builds.
BTW, as part of this progress, its decided we rewrite the GUI into something a little more flexible for cross platform code: Qt. So far, we have a basic window widget, plus a nice cheat widget too. I am currently working on the main settings dialog, making a tabbed options box with the main options in there. This was done to fix the insane mess in there currently with the *shudders* MFC GUI...
We still have a long way to go, at least it WILL be worth it in the end.
Oh you don't know what VBA-M is? Well, it is a project aimed of taking all the good bits out of every VBA fork, and sticking them in one, thus, end users no longer have to stuff around with heaps of useless builds.
BTW, as part of this progress, its decided we rewrite the GUI into something a little more flexible for cross platform code: Qt. So far, we have a basic window widget, plus a nice cheat widget too. I am currently working on the main settings dialog, making a tabbed options box with the main options in there. This was done to fix the insane mess in there currently with the *shudders* MFC GUI...
We still have a long way to go, at least it WILL be worth it in the end.
Monday, February 11, 2008
NDSFE Source Code
Okay, decided after a sudden change of thought, the thing's getting open-sourced:
http://vba-m.ngemu.com/personalfiles/ndsfe-src.zip
Licence is in the NDSFE2.CPP file, under a BSD licence. This should allow for a Qt4 port now.
http://vba-m.ngemu.com/personalfiles/ndsfe-src.zip
Licence is in the NDSFE2.CPP file, under a BSD licence. This should allow for a Qt4 port now.
Sunday, February 10, 2008
One final thing...
I have managed to slowly, but steadily work more on the firmware editor. One final thing remains. Unicode text input with my hack. If I can get this to work, then the NDS firmware editor will be released in public beta form. Otherwise, I might just disable it for now, and release anyway, until that is done, then release proper. After this, there is plans for a Qt4 GUI, and unfortunately, that involves opensourcing the whole thing...Which I dont want to, as this is special to me...
Saturday, February 9, 2008
More updates...
Did some further work on the firmware editor...
Now, the number fields are locked to 2 characters in size. Rather simple
Not to mention, Drag N' Drop works now too for file handling :)
The file input box only accepts filenames with the *.bin extension, so that you don't load the wrong type. Also, there will be bytechecks post release to see whether a file is a real NDS firmware or not. I might need some people to help test it though, and I might need some testers to see if things work alright when release time comes. Which I am hoping to be extremely soon, as I know plenty of people are awaiting this, and I don't want to dissapoint.
Now, the number fields are locked to 2 characters in size. Rather simple
Not to mention, Drag N' Drop works now too for file handling :)
The file input box only accepts filenames with the *.bin extension, so that you don't load the wrong type. Also, there will be bytechecks post release to see whether a file is a real NDS firmware or not. I might need some people to help test it though, and I might need some testers to see if things work alright when release time comes. Which I am hoping to be extremely soon, as I know plenty of people are awaiting this, and I don't want to dissapoint.
Friday, February 8, 2008
Upcoming Glide64
Just thought I'd post some of my experiences with the new Glide64 version.
There are some pretty major updates to emulation. Here's just a few:
* Conker's Bad Fur Day is now emulated perfectly. Yes you heard right: This game, when emulated, now looks 100% identical to real N64 hardware. Considering this is the most technically taxing and impressive N64 game out there, this is saying something.
* YUV texture support. These framebuffer textures are now natively supported. Games like Bottom of the Ninth use this for image representation purposes.
* 32-bit texture support. Needed for the Japanese version of Pokemon Stadium.
* rdphalf microcode commands are emulated. This is used for Perfect Dark and GE 007 sky. Which also means Perfect Dark is, perfectly emulation.
* Not to mention on top of that, full high resolution texture support.
There's loads of other nice things too, but it will take all day to list them....
There are some pretty major updates to emulation. Here's just a few:
* Conker's Bad Fur Day is now emulated perfectly. Yes you heard right: This game, when emulated, now looks 100% identical to real N64 hardware. Considering this is the most technically taxing and impressive N64 game out there, this is saying something.
* YUV texture support. These framebuffer textures are now natively supported. Games like Bottom of the Ninth use this for image representation purposes.
* 32-bit texture support. Needed for the Japanese version of Pokemon Stadium.
* rdphalf microcode commands are emulated. This is used for Perfect Dark and GE 007 sky. Which also means Perfect Dark is, perfectly emulation.
* Not to mention on top of that, full high resolution texture support.
There's loads of other nice things too, but it will take all day to list them....
Thursday, February 7, 2008
Recent stuff
Well what can I say? I have been very busy with my personal life and all, yet I still find time to work on things. :)
Here's a little preview of what is my recent work
Not too shabby eh? For those that wonder, this is a Nintendo DS firmware editor. This is written based off a idea Squall made. Of a automated way to edit NDS firmware. Currently I'd say the thing is 80% functionally complete. What is left to do is:
* Add support for Unicode strings (bleh)
* Implement CRC16 modbus calculations on the required data
As you can see it uses Windows XP themes. It does so without requiring a manifest, by embedding the manifest inside the executable. Its also coded in pure Win32 C++, which I am proud of. Sadly though, due to the Unicode routines, I have my doubts this will run on legacy OSes. But thats not that important, considering it runs fine on Vista and XP SP2/SP3...
Here's a little preview of what is my recent work
Not too shabby eh? For those that wonder, this is a Nintendo DS firmware editor. This is written based off a idea Squall made. Of a automated way to edit NDS firmware. Currently I'd say the thing is 80% functionally complete. What is left to do is:
* Add support for Unicode strings (bleh)
* Implement CRC16 modbus calculations on the required data
As you can see it uses Windows XP themes. It does so without requiring a manifest, by embedding the manifest inside the executable. Its also coded in pure Win32 C++, which I am proud of. Sadly though, due to the Unicode routines, I have my doubts this will run on legacy OSes. But thats not that important, considering it runs fine on Vista and XP SP2/SP3...
Subscribe to:
Posts (Atom)