Jump to content

  • Log In with Google      Sign In   
  • Create Account

ShyGuy92

Member Since 16 Jan 2010
Offline Last Active Nov 24 2014 11:51 AM

Posts I've Made

In Topic: Perfect Directory Structure for Game + Tools

05 August 2013 - 09:39 AM

I wouldn't split my headers from my cpp files

I haven't split up the headers and sources...?

I've edited the directory structure. All program and tool sources come into the same src-directory (with subdirectory). The src-directory might also have lib*-subdirs, which include the source files of project specific libraries. Such a library might be used for reading and writing custom file formats (e.g. level files), which might be used by both the final game and the level editor (a tool).
In addition the tree now have a certain place where to put the distributable files (in general copies of the bin and share folders, packed in archives, installers, etc.).

In Topic: SDL vs. SFML

16 April 2011 - 06:35 AM

I also want to add some points to the both libraries, as I'm also not always sure which one I should take:

SDL (1.2)
+ direct draw on surfaces: might be useful in special cases, such as emulators, dynamic images or regularly rendered maps
+ 8-bit sprites: very useful if you want to code retro-like games (such as a Super Mario fan game), as you can play with different palettes
? I'm not sure, but I think there are some problems on Windows switching to fullscreen or back during game play
- it has got it's own cursor for the window, what some people might not really like

SFML
+ native PNG and other image files support without any add-ons
+ native Ogg and other audio files support without any add-ons
+ native network support without any add-ons; simple intereface for HTTP
+ native TTF and other font files support for text drawing without any add-ons
+ multiple windows
+ fast sprite transforming (scaling, rotating etc.) without any add-ons
- might not work on every hardware where SDL does: for me it didn't work with Linux on one of my PCs
- no 8-bit sprites for playing with palette switches

In Topic: OpenAL Streaming (Queue Buffers)

16 August 2010 - 03:21 AM

Okay, I changed sleep time from 92ms to 20ms, and I don't notice any more CPU usage (program uses 0-3% CPU). I listened to a stream for many minutes and there seemed to be no interrupt.

Maybe that's really the solution now :)

In Topic: OpenAL Streaming (Queue Buffers)

15 August 2010 - 01:38 PM

Quote:
Original post by KulSeran
Quote:

What might be the problem? Could it be that the program "miss" the time to update the stream and the source stops?

Seems you didn't read what I said about sleep. If you say "sleep(92)" the program won't return for ATLEAST 92ms. It doesn't mean it will return after exactly 92ms or before 92ms. It will only return sometime after 92ms have passed. There is a really good chance that you are going to miss your window (windows is granular on sleeps with about 15ms of jitter). You need to sleep for less time, and poll OpenAL to see if the buffers are ready to be filled (looks like "number of processed buffers can be detected using an alSourcei call to retrieve AL_BUFFERS_PROCESSED").

The calculation of buffer duration results (~)92 ms. That means, with all the lost time for other code in the thread and somewhere else it should be VERY propably that 1 of 4 buffers is processed. That means after sleeping there should be a buffer to fill.
Even if I haven't slept enough and there's no buffer to fill, after 92 more ms there must be 1 or even 2 (of 4) buffers to fill, but (usually) never 3 or 4.

(I have a "semi-solution": If the source stopped for some reason I just resume it. Still I might get a short moment in the stream where just nothing is to be heard.)



Quote:
Original post by KulSeran
There is a really good chance that you are going to miss your window (windows is granular on sleeps with about 15ms of jitter).

What do you mean by that? What does a thread in the background have to do with a window?


Quote:
Original post by KulSeran
You need to sleep for less time, ...

But if I sleep less then 92ms (the duration of a single buffer) it is more propably that one buffer is processed yet and I waste CPU.

In Topic: OpenAL Streaming (Queue Buffers)

15 August 2010 - 07:54 AM

It happened again. I listened to a (looping) song for some minutes and it suddenly stopped again. Buffer size is 16384 bytes, and there are 4 buffers.
The calculated sleep time is 92 ms and the song is played at 44.1 kHz.

But the program itself does nothing which might "stop" the song. The main program code just waits for user input (cin.get()) while the thread is updating the processed buffers and sleeping 92ms after all buffers filled and queued.

What might be the problem? Could it be that the program "miss" the time to update the stream and the source stops?
Is it maybe possible to tell the source to loop the last buffer or something until there are new buffers queued?

PARTNERS