Skip navigation

Howdy all !

Here is the second version of the renderer preview, highlights in this release:

Sound !! — all M30 OJM’s should play fine !, although sometimes it will give you a warning, it will make the best effort to play the file. If you find any M30 file that isn’t playing, please tell me, also send me the file, if possible.

Less lag ! — I re-wrote the rendering loop, the animation should be a lot smoother now, specially on fullscreen.

Precision — Sometimes the notes where being placed a bit off the mark, It should be like o2jam now, except for the long note head, it still might be some pixels off.

Interface – You can maximize the music selector, there’s a text box to search for the songs faster, and you can now select any hispeed from 0.5 to 10 in 0.5 intervals.

That’s it for now I guess, I’ll be working on the BMS and the other OJM types now.

download here: renderer preview 2

cya.

Advertisements

Finally, the first renderer preview is here ! but before you try it please read below.

First things first, it was made in Java, why ? well, because now you can run this not only on Windows, but also on a Mac, linux or any other platform that have Java.

So, you must be sure you got the lastest version of java installed.

After that, you should be able to run it, extract the files from the zip and run the open2jam.jar file.

I tried to pack as much as I could without complicating things, so there’s a button on the upper left corner to choose the directory with the ojn files, after selecting the folder, it will load all files on the program so you can choose which you wanna see playing, there are hispeed and rank control’s which I think it’s pretty self explanatory, and on the display section you can choose how the renderer window will be, after choosing all that click the “Play!” button and the rendering should start. You can close the rendering window by pressing ESC.

Some warnings:
1. You can’t play it, no really, it’s just to see how the rendering works for you, sound also is lacking now.
2. Resolutions other than 800×600 will make the notes size different from o2jam, that’s because I didn’t made it resize yet.

“Wait a second why are you releasing this if we can’t play ??”
– For 2 reasons, test and test.

Test if the rendering of the notes is as you would expect, if there’s nothing differing from o2jam( off-course there is, where is the question).

Test the rendering speed, on my pc it’s pretty fast +1k fps, but I would like to hear how it goes with other people.

That’s it, now you can download it here and see for yourself.

Concerns ? suggestions ? errors ? post then below and I’ll try to help.
Thank you.

The last piece of the puzzle( so far ?) is the BPM, after some some research I’m almost sure the BPM – measure relation boils down to this constant:
1 measure per second @ 240 BPM.

That means if the song is playing at exactly 240 BPM, one measure will take exactly 1 second to pass the judgment line, that is if we start a timer when a measure pass the line and stop it when the next measure starts we will have 1 second in the timer.

From there, we can calculate the time of the measures in other BPM’s like this:
bpm x = 240/x seconds per measure.
so, a measure at a song playing at 160 bpm will take 1.5 seconds.

With that, and the measure sizes, we can finally calculate each note’s movement speed:

let’s say the hispeed is 3x and the bpm is 150.
so each measure is 1155 pixels ( 3*385 @ 800×600),
and each measure takes 1.6 seconds, or rather, we have 0.625(1/1.6) measures per second.
If we have 0.625 measures per second, we can find how much pixels of the measure we have per second:
0.625 * 1155 = 721(.875) pixels per second.

so a note moves 721 pixels per second at 3x and 150 bpm.

with this, we got all the tools necessary to build the renderer, which is the part of the program that put the notes in the right place and show that in the screen. In fact, I did just that, my implementation of the renderer is almost done, I just need to build some interface around it, so that you can choose songs, speed, etc, and I will make a “preview release” to allow people test it. Don’t get your hopes build up though, it won’t be playable, yet.

So far we know how the notes are displayed inside the measure but not how the measures are displayed as a whole, the notes position inside the measure is independent from the hi-speed, but the measure size( only height actually) is direct affected by the hi-speed.

On o2jam, the native resolution is 800×600 but not all of those 600 pixels are used for the notes( we got the interface, etc).
I found that the usable space, that is, the area where the notes falls, is 480 pixels and, at 1x hi-speed, each measure is 384 pixels, the hi-speed multipliers are direct applied at the measure size, so at 3x the measure is 1152 = 384*3.

We could stop here already, but I don’t think 800×600 is good enough anymore, but we can’t just use the absolute values, since it wouldn’t be using the extra space at all then, and making the usable space bigger would give some sort of advantage.

We need to maintain the scale of the usable space at any resolution, we need to use the ratio:

480/600 = 0.8, so the usable space is 80% of the screen size !, and..
384/480 = 0.8, coincidence or not, the measure at 1x is also 80%, but of the usable space.

then we can apply the hi-speed multipliers at the ratio instead.
e.g.: at 0.5x each measure is 40% of the usable space, and at 5x it is 400%(4 times) the usable space.

Following this, we can scale the measures at any resolution, example with 1024×768:

768 * 0.8 = 614(.4) pixels of usable space.

0.5x -> 614 * 0.4 = 245(.6) pixels of measure size.
1x -> 614 * 0.8 = 491(.2) idem
2x -> 614 * 1.6 = 982(.4) idem
… and so on.

Note however that depending of the screen size the scale won’t be perfect, since we can only have whole numbers for pixels.

So is it over now ? Nope. There’s still one variable not accounted for. The BPM. Which I’m guessing it isn’t relative to any other thing. That is, a magic number that determines how much of a measure moves in a second. But I think it isn’t a direct mapping, there should be some ratio here.. how much that is the question..

If you had showed me earlier this I wouldn’t had start from the scratch !
well at least now the OJN is pretty much complete…. still searching for the tricky OJM though …

parent: The OJN Documentation

Before diving into the notes section is important to define some terms:

events: The notes section doesn’t just contain the notes, it also has the bpm changes of the music and auto-play samples( pieces of music that play automatically as the music goes that doesn’t depend on the player, it usually appears at Ex(easy) songs), and perhaps other things I’m not aware of.

measure: Ever noticed those horizontal lines in between the notes during the music ? Those are the measures, we say all the notes before the first line are ‘measure 0’, after the first we call them ‘measure 1’ and so on.

package: These are the blocks that form a note section, each package contain one or more events inside.
Each package correspond to a specifically measure in a specifically channel( see below).
The number of packages in each section is in the package_count variable in the header section.

Each package has a mini header as follows:

struct package_header {
        int32   measure;
        short16 channel;
        short16 events;
};

measure: This is the measure in which the events inside this package will appear.

channel: This determines the events type, so far a got these:

channel  meaning
0 measure fraction
1 BPM change
2 note on 1st lane
3 note on 2nd lane
4 note on 3rd lane
5 note on 4th lane(middle button)
6 note on 5th lane
7 note on 6th lane
8 note on 7th lane
9~22 auto-play samples(?)

events: The number of events inside this package.

Each event has, as far as I know, 4 bytes, and the effect of the event depends on the channel.

When the channel is 0(fractional measure), the 4 bytes are a float, indicating how much of the measure is actually used, so if the value is 0.75, the size of this measure will be only 75% of a normal measure. This pretty rare to find a song using this, one example is Phase 1 on Easy at the measure 42( roughly 1:05 min).

When the channel is 1(BPM change) these 4 bytes are a float with the new BPM.

When the channel is between 2..8(note), these 4 bytes are divided like this:

struct note_event {
        short16 value;
        half-char volume;
        half-char pan;
        char note_type;
};

value: when value is 0 the event is ignored ( see below why), otherwise this is the reference to the sample on the OJM file.

volume: The volume to play the sample from 1~15, and 0 is the max volume.

pan: The panning of the sample, although this can also be controlled using stereo samples, further control can be given by using different pans with the same sample( I guess).
1~7 = left -> center, 0 or 8 = center, 9~15 = center -> right.

note_type: 0 when it’s is a normal note, 2 when it is the start of a long note, and 3 at the end of a long note. And a 4 value indicates the use of an “OGG sample”(in the notetool), despise the fact you can use ogg in the WAV section.

As you could see, each package can have more than one event, in these cases, the position of the event inside the measure is determined dividing the occurrence by the number of events. Example: if you got a package with 16 events, the 8th event will be at the middle of the measure(8/16=0.5), that’s probably why we have those ‘ignored events'(value = 0), they are there for padding the real events in the right position inside the measure.

See the about page