The problem doesn't appear to be with looping, but how to have the song speed up, without affecting the pitch, on the fly when the player picks up the speed boots. Solve that and feel free to use OGG, it's just at this moment in time, it's a little difficult to do with OGG/MP3 etc. (and from what I've heard of Media Player trying it, it sounds shit anyway).
Told you, it can be done with FFTs, but I don't think it is a feasible option in real time. Unless your target platform has the computational power of Deeper Blue.
First, I don't see why XM is so retarded. Second, the use of XM was merely a suggestion to make the speed shoes a non-issue because you'd just change the tempo, instead of dicking around with all this shit about trying to sync two versions up melodically or realtime tempo shifting. But, as I said, it was just a suggestion, and if you're so vehemently against it then it guess you guys can spend the time figuring out how to make speed shoes work seamlessly with a non-tracked format.
Just use a second set of MP3s, then have the track start from the beginning when you collect shoes. It should sound okay.
Don't forget to view my first post: http://forums.sonicretro.org/index.php?s=&...st&p=194684 Opinions? Especially about creating some sort of protocol What I didn't mention was that Down/Right vectors can create scaling as well. Also, the offset should always be applied first when doing the matrix multiplication Finally, I forgot to mention the aspect ratio. The Tile Engine can call System_getAspect() before drawing the tiles Function ideas: layer_register() layer_unregister()/layer_kill()/layer_delete() system_getAspect() system_getTicks() event_callFunc(FunctionAddress, InHowManyTicksToCallTheFunction) //Adds a function for the event manager to execute input_checkKey() //Returns True if key was pressed; If Key is being held down - it keeps on firing input_lockKey() //Ignores the key in software input_unlockKey() //Un-Ignores a key input_forceRelease() //If a key is being held - it'll keep on firing. Calling forceRelease ignores the signals UNTIL the user physically releases the key mem_alloc(AllocGroupID, AllocSize) //Check my previous post for info on these mem_free() mem_reset() mem_refresh()
When reading all of that my mind is going... "Memory allocation wrapper? C code? Comic Sans? Layer registration?" What are you trying to do? None of that is coherent.
"What are you trying to do? None of that is coherent." "C code?" <-- what, you have a problem with C code? "Memory allocation wrapper?" <-- I thought this was self explanatory, but basicly: malloc: Code (Text): sprite1=malloc(...); sprite2=malloc(...); sprite3=malloc(...); sprite4=malloc(...); sprite5=malloc(...); free(sprite1); free(sprite2); free(sprite3); free(sprite4); free(sprite5); Vs. mem_alloc: Code (Text): sprite1=mem_alloc(STUPID_ID_GOES_HERE, ...); sprite2=mem_alloc(STUPID_ID_GOES_HERE, ...); sprite3=mem_alloc(STUPID_ID_GOES_HERE, ...); sprite4=mem_alloc(STUPID_ID_GOES_HERE, ...); sprite5=mem_alloc(STUPID_ID_GOES_HERE, ...); mem_free(MEM_ID(STUPID_ID_GOES_HERE)); Now do you see how that is useful? It is a wrapper because it "wraps" around malloc/free to create something with much more depth "Comic Sans?" <-- What's wrong with Comic Sans? "Layer registration" <-- You're not paying attention; It's a tilemap. One uses layer_register() to send the tilemap to the graphics engine
A better question is what's RIGHT with Comic Sans. ;P And for what it's worth, it might just be easier to have 2 sets of OGG/MP3s and just doa calculation based on a known speed difference - if your music is sped up by say 50% (it's not, but this makes the sums easier for this example) and you're 3 seconds in, you know you should be at 2 seconds in the sped-up MP3.
I don't see how the malloc wrapping code is relevant to this thread at all. Your second post is hard to follow. I assume that you're trying to define an interface to a tile engine, which is fine. Why would you want to do this in C? Do you really want to get bogged down with memory management and weakly-structured code?
The problem with this approach that we were discussiong earlier was the problem with audio syncing issues. The sped up music has to be buffered pretty much instantaneously to ensure that no skipping happens, and the audio engine could screw up keeping track of where it needs to be. This problem is a theoretical problem, but if it happens, it's going to be very hard to fix. I remember when I was doing my cheap sonic/mario mashup I had problems with this same thing, although I blame it on Java and its cross-platform crap in the middle.
Regarding the power sneakers issue, I think I have found a start to the solution. There's an open-source audio library called SoundTouch that can do fixed-pitch time-stretching in real time. The latency on the algorithm is supposedly about 100 ms max; this is definitely less time than the difference between striking the power sneakers monitor and the speedup of the music. This sounds like it could help solve the problem if somebody was to implement it. There are two catches however. First, the algorithm is of a type that doesn't handle sudden spectral changes well (like percussive sounds), but I don't know if this is actually going to be an issue until we implement it and listen to the changes. Second, it is only implemented for WAV, not OGG or MP3. I don't know if there're any similar libraries that support those formats or not.
Hey so... I'm not a programmer or anything but I wanted to offer some insight... The super sneakers in the original Sonic 2 trigger the music to accelerate to to a faster pace. What might work from my limited understanding of programming is when the sneaker box is activated... well, first you guys need to designate what the duration time will be for Super Speed. Next you will want to determine how much faster the tracks will be playing using a round percentage like 120% or 130%. Whatever the percentage it will be, have all the musicians render their music tracks in their original BPM and then EXACTLY (x)% down to the thousandth or hundredth of a BPM if possible. Then you I believe you will want to refer to the timecode in # of seconds. If your original is 100.000 seconds long... then your sped up version will be (for example if 130% of the speed) (1.000/1.300) * 100 = 76.923 seconds. Whatever the time elapsed on the music track is (before the sneakers are activated) will point to the timecode on the sped up track that you want to be playing from a certain point by the simple transformation: TimeElapsedSpedUp == (1.0/1.3)*TimeElapsedOriginal and the reverse transformation for when wanting to switch back to the original speed track. Whatever ogg file is playing will need to buffer ahead 500ms or so to get a smooth transition I believe. Hope I wasn't stating the obvious... programmers I'd think might have this down... but I mean I'd like to think I contributed hahaha... Btw... I believe in the original game it bends up... from my limited knowledge once again... I just noticed that library that allows you to render non-pitch time stretching. If you use that to bend the time UP and then have it buffer to the right position on the sped up track after that then you have a nice bend up and down! All you guys gotta do is calculate how much time the bend will take and what position (TIME IN SECONDS) that it ends up at and then you can transition into the faster rendered track and vice versa for the end of the power sneakers effect! (bend down, get timecode, relate back to the original speed track). Hope I helped!
"I don't see how the malloc wrapping code is relevant to this thread at all." I don't see how it's not... The goal is portability, and no, not just "OMFG, LET'S GET IT TO RUN ON LINUX x86 AND WINDOWS x86!!! LOL!" I'm talking about Dreamcast, Xbox, PS2, etc. 1) Not all systems use malloc() - some are much more of a bitch to set up 2) So by using 'malloc' all over the code, one's only making it harder to port 3) And you might be thinking, "how hard is that - just rename malloc to whatever's needed" 4) But no, some systems have a malloc that uses two arguments and requires the programmer to do page management himself 5) So by wrapping malloc, one can just go to mem_alloc() and do all the memory handling code there in order to port the game 6) This means that the game engines themselves can be ported, without touching the game code "Why would you want to do this in C? Do you really want to get bogged down with memory management and weakly-structured code?" 1) C's compatible with C++ 2) With the different systems out there, a C compiler is much easier to obtain 3) Therefore when it comes to writing code on other systems, a C compiler has much more support "I assume that you're trying to define an interface to a tile engine, which is fine." 1) Yes - it's an interface to a tile engine. 2) The idea is, define a common way to store the data. Again, portability in mind. 3) "It's hard to follow" - no it's not. This is how majority of tile engines in game consoles work. Go look up the GBA's tile engine. 4) By simulating the designs of a console tile engine, it makes Sonic 2 easier to port over.
Thanks for the suggestions, this is essentially what we want to do, the only problem is that this only works when that buffer behaves as it should. Switching between different sound files can cause skipping issues if for some reason the buffer doesn't fill up the way it needs to in time. Maybe I'm being naive about this, but depending on how we handle the audio code and how much of it we write ourselves, couldn't we buffer all of both songs (normal and fast speed) into memory when the level loads? I know that's a waste of memory, but if doing that could reduce slowdown, then it's an idea. As far as memory issues, I'm with SANiK on this one. Abstracting as much platform/compiler-dependent stuff as possible is best so that we don't sacrifice any portability potential for laziness. All areas of the engine should take this into consideration as well, graphics, audio, etc.) BTW, has any discussion taken place on how we're handling input? I'm assuming there will be keyboard support and even joystick/gamepad support, but what kind of an interface are we going to provide for it? (e.g. remapping keys GUI, etc)
Buffer both songs in? That wouldn't take a WHOLE lot of memory... I didn't even think of that. It can't possibly hog up enough to cause lag. Once you prebuffer it should run smoothly Just run a prebuffer of say 3 seconds for the loop and you should have it nice and smooth I think! I guess to render the BEND is seems complicated... switchin between songs and referencing timecodes is probably not rocket science to program (guys I know its hard... I failed Intro to C... of course my professor was the ultimate douchebag of the universe...) but that bending sounds tough forr reeealssss.
Right. Buffering two songs couldn't possibly cause lag. I mean, it's not like there is some sort of powerup that could change the music (perhaps making you invincible also). Nor could anybody be wearing the super sneakers when the boss music starts. And besides, ALL computers and game devices we might want to port this to somehow conveniently manage to have a crapton of memory. Yeah. [/sarcasam] After all, if you have to have not just TWO, but EIGHT songs loaded at once (one normal, one sped up for each of the following: level, super sonic, invincibility, boss), things start to become clogged. Alright, so you only have to have super sonic pre-loaded once the player has all seven emeralds, and you only need to preload the boss music after a certain point on the Act 2 of each level, but still, that's FOUR songs always loaded, at least, sometimes six, and possibly eight. So yes, loading ALL into memory and doing all that stuff to make it work. Possible? Yeah, seems like it. Is it the most efficient? Probably not. Is it portable? Also probably not. I don't know, perhaps there is some SUPER EFFICIENT system that can do all this and make toast. But I doubt it would be easily ported to various platforms.
The Super Sonic music is never sped up in Sonic 2. Now try this: start the drowning music (sound 1F) and repeatedly play (I'm using the auto-fire in Gens Movie Test for this) the speed-up sound (sound 7B) or the speed-down sound (sound 7C) and see how it alters the tempo (something similar happens in Sonic 1, but sounds E1 and E2 are not available in the sound test). Here's the challenge: replicate this behavior in Sonic 2 HD! :P On a more serious note, I hate when the music stops playing just because the game has to load the data. Preloading a few seconds from some tracks could prevent this issue, but I'd be unnecessary if the music loading system is very fast. Before the boss music starts, the current music fades out, so there would be no need to load it before that, unless the process very slow.
How about chunking and sequencing the stage music into smaller audio files (e.g. emhil_01.ogg, emhil_02.ogg, etc.) and only having to load a few seconds worth of music into memory rather than the whole songs? This way less RAM is needed and all the audio engine has to do is keep track of which chunk goes next from which chunk set. A sort of pre-sampling in a way. It will cause a lag between the initial hit of the monitor and the speed up and speed down though. Just an idea.
Something like this could work, perhaps split it up by how it musically fits, for instance, intro, chorus, verse, bridge, etc. But really in the end, we're not going to be able to solve this problem until some actual implementation is started. I really think we should sort out this war over sampled (MOD/MIDI/XM/whatever) vs (OGG/MP3) first. Can we get the musicians of the project to chime in? (Perhaps cross-post some of this conversation from this thread into the music thread so we can get the initial flames and figure out the pros/cons of it from their angle. I know earlier someone complained about how they'd leave the project if we switched to XM, but I'd like to hear some more explanation from everyone on that end of the spectrum.
That someone is your esteemed admin Tweaker. I think his reaction is a bit extreme, but I most definitely see where he's coming from. Working in a tracker to compose music is more laborious and less intuitive than working in a sequencer for most of us.
