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?

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

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.

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.

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.

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.

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.

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.

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.

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).

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).

Who is online

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum