Sorry your browser is not supported!

I've hit a snag that I'm not sure I can fix. I have a game engine running which has multiple soungs that play (21 to be exact) randomly in the background, moving one to another when the previous one ends. Now, as they are not as long as a level, they change several times, which resulted in a "blip" in the frame rate when the new track loaded (I don;t want to hold them all in memory). So, I wrote a simple stand alone exe for the purpose that is called and ended when needed by the game, hence allowing seemless background loading of the music. I;ve recoded them as WAV files from 15-25 meg and there is no noticable pause at all this way, however I have a couple of questions. When calling the music player, the command says you can assign normal or high priotity - but I want it to be low. I've tried minus figures, but to no avail. Can you alter the windows task priority via DBPro?

Also, and unrelated, can I pass variables to the program? For example, a specific song to play? The reason I ask is, the system will allow streaming of data quietly in the background, but only if it can be passed data such as world coords. Is this possible? AMOS (for the Amiga) used to have PEEK and POKE, DEEK and DOKE commands that would allow you to manually locate a fixed memory location, and write to it - that way another exe could easily load from it. Can two .exe files be set to draw to the same screen (i.e. - the background app drawing a city which is streamed, while the main exe handled everything else)? Any thoughts???

Dunno about tasking priorities as this feature is new and I've been using an old dbp till recently. However, passing data to and exe is easy. Use the CL$ function in your target executable to retrieve data passed to it when calling.

As for music, why don't you simply preload 5 random songs per level. That way you don't need to load them all at once but you have plenty of variance. Just a thought. Worst case scenario (based on the size you specified) is you use 100mb memory which is nothing on a modern system.

Total sidenote but I remember POKE and PEEK from the good old days, heh

[EDIT] Just to clarify what I mean, here's an example



You can also use EXECUTE EXECUTABLE in newer DBP version which will return the process id (retval = EXECUTE EXECUTABLE etc). I've yet to use it (only just got the new DBP) so I don't know if it works better/differently/worse or not. The reason I used PLAY SOUND and not PLAY MUSIC was because there are more SOUND commands than music commands so in a way it's more versatile. Also, they prolly corrected this bug in the new DBP, but I got very unsmooth looping with music commands and ended up having to write an internal event timer in my last game. After the fact I did some experiments with the SOUND commands and wished I'd gone that route but it was too late t re-code.

STYX is what you want as it features everything you are looking for... interval loading should also help reduce that *blip* issue and it also has PEEK POKE functions...

Hope this helped...

Sorry I can not currently answer the priority question at this time... but are you setting it to minimise on start?

I've heard of STYX mentioned a few times, so I'll give that a google. I actually got the priority thing sorted not long after that post (using kernal32.dll), so it was mainly the PEEK and POKE functions I wanted, but I hit a wall. The music loader I open as low priority, the main .exe I make high, then the music exe I loop using "sleep sync 1" so that it averages 0-1% processor usage - yet oddly I STILL get the 10% frame rate hit in the main .exe simply by having the other program loaded. Even if I remove the music and just have the music .exe sit and do nothing, the hit is still there, so I assume that DB simply isn;t designed to share anything. Lol.

Can I ask what is meant by interval loading? And I don;t hold the music in ram as the intention is to increase the overal number of songs, and I'm also seeing how effectively the system could stream data. For example, a skyrim style world. MEMBLOCKS of graphics background loaded and deleted based on which "zone" the player was in, and then the start position of the block passed to the main .exe to use the graphics - hence the PEEK, POKE requirement. Lol.

http://www.thegamecreators.com/?m=view_product&id=2079

a lot of what you are trying to do is solvable in STYX

just read the product page and let me know if it makes you drool too heh

if you need me to look into any particulars like in the help files for something specific just ask

Hey, dunno how helpful this would be, but (I'm assuming now, based on your other post that you need a constant flow between two programs):

1) Check this thread out. http://forum.thegamecreators.com/?m=forum_view&t=39187&b=1 IanM's got some code you just need to compile! I think this prolly makes life the eaiest

2) (Theoretical, haven't tried it) You can use MAKE MEMORY to create your own memory blocks. Haven't ever had cause to use it so I'm unfamiliar with it I'm afraid, but from what I understand, the variable used when creating the memory chunk stores the address and placing a * in front of the variable accesses the actual data (points to the first byte). So maybe you could pass the initial address to your other exe and then the two of them could communicate within that piece of memory?



Hope it works

You can't do this since a process can only see its own memory, although the shared memory approach IanM mentions in that thread is a good alternative. Still, I wouldn't recommend running another process just to handle music playback, I'd look for a library that can do something similar.

CAUTION FLASHBACK!!!
the last few posts brought back the long forgotten memory of CD PLAYBACK MUSIC TRACKS...

Oh AOEII where are you!!!

try using intervals... or I could try it... hey anyone know of the best way to play FLAC files through DBPro? I ask because I have OCREMIX which only has MP3 or FLAC files I could try converting but my main rig is innaccessible at the moment...

Cheers for the advice guys. The system I was looking at was (wait for it!!!) - two programs, one the game, the other the loader/deleter. I found a plugin that has peek/poke and deek/doke (yay - they can locate a free mem address then write bytes to it - a fixed address - so this address is passed as a variable to the second exe when it's started and hey presto: multi program communication). So, the plan would be:

A world split into "zones" (think graph paper) with each zone having a data file stating which objects/textures etc are needed for it. As the player moves their "zone" ref is poke'ed into memory, where the other .exe peek's it back out again, hence knowing where the player is. Once they cross a boundary, it checks the next sections that need loaded, then loads memblocks into ram (using the ref as above), then poke's this address back to the main game. It can then grab files from the memblock and load them to regular memory and draw them to the screen (this is the hicup - that's bound to stutter but still not as badly as loading from HD - ideal solution is some way of "sharing" the memory so cross use is possible: i.e. second .exe loads model 1, first .exe can then just place it, but that's not possible I don't think!). Old area's simply have their mem blocks erased ready for new ones.

There are other advantages also of just sound - for example, walking down a street and passing people, shops playing music, noisy buildings - anything - then poke the background sound that needs to play. Second program picks this up, then loads the sound, plays it, monitors when it ends, and deletes it, or loops it until the main .exe poke's otherwise. Instantly...muttering pedestrians and noisy shop fronts/bars etc without any main exe slowdown.

Anyway, largely hypothetical right now beyond sound, but my current game runs at 62-65 fps when music is handled internally, then only drops to around 56-60 fps when the music is handled externally - and that's with large WAVS (for testing) loading over and over so it's transfering and using roughly 1500 meg per minute in files ranging from 15-25 meg (and that's giving each song one seconds playtime too - honest!!). As the engine has a custom frame rate handler, I can set that anywhere I want - if it's set to cap at 50fps the player never actually notices. So, scope is there I think.

On a side note about nostalgia.....anyone recognise what I mean when I say "AMAL" sprite animation? Literally never got that to work properly! Lol.

P.S. MrValentine,

The second .exe starts hidden so it never actual presents. I managed to get kernal32 to alter the taks priority so that the music handler is low, and the main exe is high - but it barely made a sifference. Now, I have a quad core, so I wonder if there's a way to control affinities. Maybe if I set the music handler to just a single core??? That might quarter my slowdown. Lol.

Oddity. OK, managed to assign different threads to each process as follows:

Which starts the main engine, then changes it to high priority and assigns it's affinity to core 2. I do the same at the start of the music app, but alter the priority to background only, and set it;s affinity to core 1. Now I have a quad core processor - with this set up I am now back up to 60fps with the same previous set up. However, if I leave the main exe with access to all cores, it drops back down. Anyway, it seems to work. Yay.

I believe you will have issues further down the line unless you stick to just the one core per app... but this is an interesting find... I am sure some will find it useful

Well, DBPro apparently doesn't like multi-threading at all, however isolating the music player to core 3, and allowing the main .exe to use all BUT this seemed to reduce the frame rate drop to 1-2 FPS. I wonder if four .exe's on seperate threads could work in tandem at a decent frame rate? One to play the game, one to load data, one to handle physics etc and one for sound? Interesting. Lol.

Anyway, after some playing...
http://forum.thegamecreators.com/?m=forum_view&t=193367&b=1&p=0