3.3.0 is out in North America!
DrZogCreated:
So now we just need information on when the Wii U version is coming out. A lot of companies need to communicate with their fans better than just giving them the silent treatment for long periods of time. :(
Wow, they haven't even updated their own website yet? Smilebasic.com doesn't mention the latest update yet. That's rather lazy and dumb lol. Not that it really matters, though.
So now we just need information on when the Wii U version is coming out. A lot of companies need to communicate with their fans better than just giving them the silent treatment for long periods of time. :( Wow, they haven't even updated their own website yet? Smilebasic.com doesn't mention the latest update yet. That's rather lazy and dumb lol. Not that it really matters, though.I wish that instead of creating the Wii U version, SmileBoom had just... uhh... done anything else. not only will it be absolute HELL to make the 2 versions fully compatible, but I just don't like the wii U or home consoles in general...
It's 500 yen in Japan (4.70 USD or 5.90 CAD as of now), and factoring in development costs I think it's more reasonable than, say, arcade badge plays.I don't understand...6 CAD is apparently 4.78 USD, so you're actually paying less (I think)Its not the price for the dlc it's the price per new command that is irking us.
So most of the features in Lumage's april fools prank was real? Cool.
3: CHR$(13) is still converted to CHR$(10)
Previously, when loading a text file, &H0D [CHR$(13)] was converted to &H0A. [CHR$(10)] However, from Ver. 3.3.0, this conversion will no longer be made.Not sure if this solved you problem or something. Do you mean they said they fixed it but it is still happening? Stuff in "[" and "]" are mine in the quote above. The reason I know the values are 13 and 10 are because in hex D=13 and A=10.
what happened was, they removed the conversion when saving/loading TXT files to and from STRINGS, but it still gets converted when saving/loading in the EDITOR.3: CHR$(13) is still converted to CHR$(10)Previously, when loading a text file, &H0D [CHR$(13)] was converted to &H0A. [CHR$(10)] However, from Ver. 3.3.0, this conversion will no longer be made.Not sure if this solved you problem or something. Do you mean they said they fixed it but it is still happening? Stuff in "[" and "]" are mine in the quote above. The reason I know the values are 13 and 10 are because in hex D=13 and A=10.
PCMStream is pretty easy to use. In case anyone is wondering, here's how you can try it out:
DEF PLAYBACK FNAME$ DIM AUDIO[0] LOAD "DAT":FNAME$,AUDIO,FALSE PCSTREAM AUDIO VAR PPCMPOS=0 WHILE PCMPOS>=PPCMPOS PPCMPOS=PCMPOS WAIT 1 WEND END DEF RECORD FNAME$ XON MIC MICSTART 3,3,4 WHILE MICPOS!=MICSIZE-1:WEND MICSTOP DIM AUDIO[0] MICSAVE 0,MICSIZE,AUDIO SAVE "DAT:"+FNAME$,AUDIO END
yeah, the problem is that only like 4 people got the DLC....
anyway, all old WAV files use 8 bit samples, because until now, there was no way to play 16 bit WAVs
so you'll have to convert them using
ARYOP #AOPMAD,AUDIO%,AUDIO%,256,-32768(use integers for your WAV arrays since they use half as much memory)
what happened was, they removed the conversion when saving/loading TXT files to and from STRINGS, but it still gets converted when saving/loading in the EDITOR.Ohhhh, ok. Thanks for replying I was getting confused.
PCMStream is pretty easy to use. In case anyone is wondering, here's how you can try it out:What's PCMStream?
What's PCMStream?It's part of the DLC audio package. It lets you play audio.
yeah, the problem is that only like 4 people got the DLC....Yeah, I probably won't actually be using much of the DLC. It's already pretty easy to play WAV files as is. I mainly bought it just to support SmileBOOM.