puNES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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.
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?
mudlord
Posts: 11
Joined: Sat Jun 12, 2010 8:05 pm
Contact:

Post by mudlord »

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...
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

mudlord wrote:I have to wonder how you got this 1.5GB download claim ;)
Microsoft's web site.
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.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Post by koitsu »

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.
User avatar
Dwedit
Posts: 4922
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit »

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.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
mudlord
Posts: 11
Joined: Sat Jun 12, 2010 8:05 pm
Contact:

Post by mudlord »

tepples wrote:Microsoft's web site
Oh, never realised it was that big...
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!
FHorse
Posts: 232
Joined: Sat May 08, 2010 9:31 am

Post by FHorse »

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. :)
FHorse
Posts: 232
Joined: Sat May 08, 2010 9:31 am

Version 0.19

Post by FHorse »

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.
FHorse
Posts: 232
Joined: Sat May 08, 2010 9:31 am

Version 0.20

Post by FHorse »

Changelog:
0.20
Implemented illegal opcode 0x80 for the "Beauty and the Beast (E) [!].nes" rom
Zelex
Posts: 268
Joined: Fri Apr 29, 2011 9:44 pm

Post by Zelex »

In Beauty and the Beast in my emu, the screen jumps up and down wildly. Did you have a similar issue?
FHorse
Posts: 232
Joined: Sat May 08, 2010 9:31 am

Post by FHorse »

no, my problem was that without the opcode 0x80, when I pressed the A button to jump, the emulator crashed.
FHorse
Posts: 232
Joined: Sat May 08, 2010 9:31 am

Version 0.21

Post by FHorse »

Changelog:
0.21
Correct some bugs in the MMC3 (NTSC and PAL) and now
all the roms that I'have tried works well.
FHorse
Posts: 232
Joined: Sat May 08, 2010 9:31 am

Version 0.22

Post by FHorse »

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).
FHorse
Posts: 232
Joined: Sat May 08, 2010 9:31 am

Version 0.23

Post by FHorse »

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).
FHorse
Posts: 232
Joined: Sat May 08, 2010 9:31 am

Version 0.24

Post by FHorse »

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.
Post Reply