nesdev.com
http://forums.nesdev.com/

puNES Emulator
http://forums.nesdev.com/viewtopic.php?f=3&t=6928
Page 5 of 49

Author:  tepples [ Sat Mar 05, 2011 5:37 am ]
Post subject: 

koitsu wrote:
tepples wrote:
Don't use (Windows|Linux|Mac OS X) at all? That almost sounds like console fanboys on Slashdot ... I hope I misunderstood you.

This isn't what I said / what I intended. I said if you're using a graphics API or subsystem layer (example: Allegro), and it does not offer proper documentation outlining how the waiting methodology works, or the author cannot explain it, do not use the API/subsystem.

Yeah, I ditched Allegro for SDL when I found out how likely Allegro's Mac graphics code is to break across Xcode upgrades and how little effort Canonical put into making sure sound still worked when PulseAudio was running, compared to SDL.

Quote:
This is in no way shape or form the same as "do not use {insert OS here}". There is no way I would advocate the latter; I am a vehement opponent of OS advocacy and a strong proponent of use-whatever-OS-suits-your-needs.

I was just worried that you had meant "If Windows is broken, don't port your game to Windows. If Linux is broken, don't port your game to Linux." But with SDL broken and Allegro broken, is there even a good framework that would save me from having to download the 1.5 GB Windows SDK and code in raw DX?

Author:  mudlord [ Mon Mar 07, 2011 6:36 am ]
Post subject: 

Quote:
But with SDL broken and Allegro broken, is there even a good framework that would save me from having to download the 1.5 GB Windows SDK and code in raw DX?


SFML?

If thats broken too...dunno what to do then.
And mingw+ some other stuff should be fine for Windows development. (used it before for some Windows stuff using OpenGL).

I have to wonder how you got this 1.5GB download claim ;) Last time I checked, a TDM-GCC compiler+headers package was 20MB, though you might need to hax the DX9 SDK a bit for it to even link against the libs. Or you can use GetProcAddress() I guess...

Author:  tepples [ Mon Mar 07, 2011 6:53 am ]
Post subject: 

mudlord wrote:
I have to wonder how you got this 1.5GB download claim ;)

Microsoft's web site.

Quote:
Last time I checked, a TDM-GCC compiler+headers package was 20MB

So far, I have used MinGW to compile C++. But some people on Slashdot insist that if you're using MinGW or another GCC-based tool to compile for Windows, you're Doing It Wrong. See, for example, this discussion.

Author:  koitsu [ Mon Mar 07, 2011 7:41 am ]
Post subject: 

I'm not really sure what to say to you guys about SDL or Allegro. I know I've used SDL applications on Win32 which do vsync correctly and *do not* take up tons of CPU time, so it's possible that indeed some VBL magic is going on behind the scenes (within the DX layer, not within SDL itself). Possibly the apps I've used which use SDL are using the newer high-performance version that uses D3D instead (which definitely does VBL syncing properly/differently, that's been confirmed by lots of people).

Again, if push comes to shove, make your main while(1) loop call sleep() with a long duration. This should definitely help -- the important part is not to leave the loop spinning for no reason.

I advocate a longer sleep duration than 1 second though; sleep(1) might sound good at first, but ask yourself why the loop has to iterate every 1 second when you know the loop does nothing other than sleep. Pick a larger value; 3600 or something sounds fine to me. Please don't blindly try to max it out (e.g. sleep(99999999999999); or some such nonsense) given that there's not necessarily a way to guarantee per architecture and operating system what the maximum permitted value is (some define it as "int", others "unsigned int", etc... you get the point). 3600 (1 hour) seems pretty good, IMHO.

Author:  Dwedit [ Mon Mar 07, 2011 7:51 am ]
Post subject: 

There's also the 4MB version of the DirectX 9 SDK that I threw together because I was sick of downloading the huge version. Just the INCLUDE and LIB files, nothing else. Many programs that use DirectX will build fine on Visual C++ 6.0.

Author:  mudlord [ Mon Mar 07, 2011 8:54 am ]
Post subject: 

tepples wrote:
Microsoft's web site


Oh, never realised it was that big...

Quote:
So far, I have used MinGW to compile C++. But some people on Slashdot insist that if you're using MinGW or another GCC-based tool to compile for Windows, you're Doing It Wrong™


I don't believe its doing it wrong at all. I guess by thier logic, even Pelles C is wrong because its not MS's lovechild. :roll:



Dwedit wrote:
There's also the 4MB version of the DirectX 9 SDK that I threw together because I was sick of downloading the huge version. Just the INCLUDE and LIB files, nothing else. Many programs that use DirectX will build fine on Visual C++ 6.0.


All I can say: YAY? Wanted something like this for years, thanks!

Author:  FHorse [ Mon Mar 07, 2011 9:01 am ]
Post subject: 

OK I learned my lesson and I promise that when I have finished successfully implement the APU, will study a better way that don't stress much the host CPU. For the moment I think that the sleep() that I use is a good compromise. In my defense I can only say that this is my first project in C, my first emulator and is also the first time that I have to do with graphics routine, SDL and compilers. Thank you all for your valuable suggestions. :)

Author:  FHorse [ Fri Jun 03, 2011 3:49 am ]
Post subject:  Version 0.19

Changelog:
0.19
complete APU emulation.
This is my first attempt with sdl sound and perhaps there may be some bugs. For now, without the implementation of frameskip, the emulator has to work 100% for not having problems with sound skip and crackle.
Changed the structure of the code and now the emu takes less than 100Kb.
Correct many many many bugs.

Author:  FHorse [ Fri Jun 03, 2011 4:21 pm ]
Post subject:  Version 0.20

Changelog:
0.20
Implemented illegal opcode 0x80 for the "Beauty and the Beast (E) [!].nes" rom

Author:  Zelex [ Fri Jun 03, 2011 6:18 pm ]
Post subject: 

In Beauty and the Beast in my emu, the screen jumps up and down wildly. Did you have a similar issue?

Author:  FHorse [ Sat Jun 04, 2011 1:15 am ]
Post subject: 

no, my problem was that without the opcode 0x80, when I pressed the A button to jump, the emulator crashed.

Author:  FHorse [ Sun Jun 05, 2011 8:34 am ]
Post subject:  Version 0.21

Changelog:
0.21
Correct some bugs in the MMC3 (NTSC and PAL) and now
all the roms that I'have tried works well.

Author:  FHorse [ Thu Jun 30, 2011 12:07 am ]
Post subject:  Version 0.22

Changelog:
0.22
Implemented all illegal opcode.
Rewrite from scratch MMC3 emulation and now really work with every rom that I've tested (for two weeks I've tryed all 5118 MMC3 GoodNES roms including Blargg mmc3 test) except for few bootleg and some chinese roms (why??).
Implemented fix for young indiana jones chronicles (thx James).

Author:  FHorse [ Sat Jul 09, 2011 6:14 am ]
Post subject:  Version 0.23

Changelog:
0.23
Implemented the save on file for the PRG Ram battery packed.
Rewrite MMC1 emulation and tested with all GoodNES MMC1 roms.
Now work without glitches the MMC3 chinese roms that in the previous version had problems (Aladdin 2 (Unl), Bing Kuang Ji Dan Zi - Flighty Chicken (Ch), Chu Han Zheng Ba - The War Between Chu & Han (Ch) an many others).

Author:  FHorse [ Wed Jul 13, 2011 3:34 am ]
Post subject:  Version 0.24

Changelog:
0.24
Implemented emulation of mappers MMC2, MMC4, ColorDreams and Camerica.
Correct a little bug and now "Time Lord (U) [!].nes" work without glitches.

Page 5 of 49 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/