OpenJazz vs. OpenJazz2

[Alister]

There have been many mentions of an OpenJazz2 over the years, but they never seem to have resulted in anything actually being released. Given Neobeo's <a href="http://www.jazz2online.com/jcf/showthread.php?t=15059">documentation of the JJ2 file formats</a>, this is a little tragic.

So, anyway. I was toying around with having JJ2 tilesets and layer 4 tiles substituted into JJ1 levels in OpenJazz. Of course, unlike JJ1 levels, not all JJ2 levels are 256 by 64. I decided it would be easier to separate the code out and load JJ2 levels in their own right. The separation was actually quite straightforward to do, following the refactoring I'd already done to support bonus levels.

If you get the latest OpenJazz source from SVN (https://openjazz.svn.sourceforge.net/svnroot/openjazz), you'll find you can load up JJ2 (inc. TSF) levels and have a bit of a run around. There aren't any events, which rather limits what you can do, but it's better than the very first OpenJazz release was for JJ1 levels.

So, what do people think? Instead of trying to recode JJ2 from scratch, how about using the existing OpenJazz infrastructure to fully support JJ2 levels?

[minmay]

Sound good, except that loading levels is hardly the most difficult part of replacing JJ2's engine.

[Sonyk]

I wouldn't be against the idea. Especially if it eventually culminated in using JJ2's JCS to create playable JJ1 levels.

...eventually.

[EvilMike]

So, what do people think? Instead of trying to recode JJ2 from scratch, how about using the existing OpenJazz infrastructure to fully support JJ2 levels?

It's a very interesing idea, but I think if you want to *fully* support JJ2 levels, you'll need to support a lot of other JJ2 features as well. The two games have extremely different styles of movement, and JJ2 levels are often designed around special moves (which the jj1 sprites won't allow for) or general quirks in the game. Basically, some (maybe even most) levels will probably work fine if converted to JJ1, but there will be a number of cases where they are incompatible.

Still, what you have going right now is really good, and a lot easier than recoding JJ2 would be. Plus, it can work as a good starting point for adding more and more compatibility with JJ2 levels, perhaps to the point where there'd be no need for anything like an "OpenJazz2".

[Alister]

I've just <a href="http://alister.eu/jazz/oj/download.php">uploaded a build</a>. Note that if you already have a version of OpenJazz, you'll also need a copy of <a href="http://www.winimage.com/zLibDll/index.html">zlib.dll</a>.

Sound good, except that loading levels is hardly the most difficult part of replacing JJ2's engine.That's why I'm asking if people are interested in taking it further.

I wouldn't be against the idea. Especially if it eventually culminated in using JJ2's JCS to create playable JJ1 levels.If all you want to do is create a JJ1 level using layer 4's tiles, that's actually quite straightforward (but beyond the scope of OpenJazz). JCS won't be able to handle JJ1 events, though. They work in a completely different way.

It's a very interesing idea, but I think if you want to *fully* support JJ2 levels, you'll need to support a lot of other JJ2 features as well. The two games have extremely different styles of movement, and JJ2 levels are often designed around special moves (which the jj1 sprites won't allow for) or general quirks in the game. Basically, some (maybe even most) levels will probably work fine if converted to JJ1, but there will be a number of cases where they are incompatible.Player movement and animations will eventually be different. OpenJazz currently uses separate code for player movement/appearance for JJ1 and JJ2 levels. Admittedly, the code for JJ2 is just copied and pasted from the code for JJ1, but I will be modifying it.

[Violet CLM]

Making good progress on Sonyk's wish, which helpfully I was already working on:
<img src="http://www.tachyonlabs.com/sam/J1LESpreview.png" title="not a mockup" />

[Alister]

Awesome! I'm guessing you're taking event settings, animations etc. from the existing level? How are you dealing with the start position?

[Violet CLM]

Worries about animations and start positions are for a later project. I do want to make another program that'll get you playable JJ2 levels with only a little input (mostly along the lines of confirming its guesses about which events you want to use), but I don't know any GUI code yet, so that's going to be a bit later down the line. This is just for people who would rather edit level layouts (but not events, animations, background effects, etc.) in JCS than J1E, so all I have to be able to port back and forth is layout, tileset, mask, and event names.

ETA: Transparency and layers 5 and 8 are good to go. So is masking but you can't see that here.
<img src="http://www.tachyonlabs.com/sam/J1LESpreview2.png" />
I'll stop posting screenshots and let discussion of the actual topic resume now.

[[GpW]Urbs]

I'm just amazed at how inventive some people in this community are. That doesn't get said often enough.
I mean, OpenJazz, then there's that whole JJ2plus thing going on and not to mention all the wicked levels and tilesets (although to be fair, with all that you guys are working on things like levels and tilesets have become so unkewl:)). And I believe there was even some JJ3 thing going on where the jj3 demo was playable online?
I mean... insane. And it's not just that you guys are inventive, all of this takes time!

*bows down and salutes*

[Alister]

*salutes while bowing down, and accidentally topples over*

There's a new version. It no longer messes up flipped tiles, or layers with widths not divisible by 4 (oops). There are also a few events.

[plunK]

Wow... this is really impressive. Id really love to get onboard the openjazz team, but i have basically no coding knowledge so there aint alot i can do

[Violet CLM]

<a href="http://www.jazz2online.com/downloads/6274/jazz-1-layout-editing-suite/">I did my thing</a>

[plunK]

<a href="http://www.jazz2online.com/downloads/6274/jazz-1-layout-editing-suite/">I did my thing</a>

....And it looks like I need to start trying to make levels.

Excellent job, this is much needed and much easier imo.

Jealous of coding skills...... XD

[Alister]

Awesome!

Unfortunately, now I have to panic about the bugs in Sonic With a Gun. :p

[Violet CLM]

I have no idea why so many sprites disappear, but it looks like most of the other problems stem from inaccurate calculation of speeds and distances. There's also some inaccurate checking of collision masks, in that the green shooty guys can only fire in OJ when they're on unmasked tiles and the spring plants rarely work (the same problem occurs in the original Jungrock). Looking ahead, the code for the thirty-eighth and thirty-ninth behaviors doesn't allow for reversing the y-axis (to create a downward sucker tube-like event), and the code for fourth behavior doesn't detect pits (it's supposed to be confined to a single platform, as in the third behavior) and doesn't stop just before reaching you.

[Alister]

Sorry it's taken so long to respond. I moved the day after posting that, and I've only had an internet connection since Friday.

The sprite problem has now been fixed - it was caused by conflicting sprites in mainchar.000 and sprites.000. I don't know how JJ1 handles this, but this should probabaly be avoided - it could be causing a memory leak. Still, I'd assume DOSBox cleans up after itself. Either way, OpenJazz now handles this correctly.

Yes, the speeds are inaccurate. I spent ages trying to perfect them back when I first started OpenJazz, but a lot has changed since then. I've been reluctant to spend so long perfecting them again, in case things change radically again. Still, at least the levels are playable now.

Starting positions for bullets have proven difficult to get right. Perhaps I could get them to ignore the mask on their first tile, or the first sequence of mask they encounter when they are generated on a mask.

Would it be possible to get an example of a downward sucker tube?

It sounds like the fourth behaviour should be easy enough to fix.

[Violet CLM]

The sprite problem has now been fixed - it was caused by conflicting sprites in mainchar.000 and sprites.000. I don't know how JJ1 handles this, but this should probabaly be avoided - it could be causing a memory leak. Still, I'd assume DOSBox cleans up after itself. Either way, OpenJazz now handles this correctly.
JJ1 handles this by using the sprite from the planet-specific sprite file, rather than the general sprite file, whenever there's a conflict.
Would it be possible to get an example of a downward sucker tube?
Behavior: Repel Jazz foreground
Modifier: Pull Jazz
Variable #1: 60
Variable #2: -1
It shoots Jazz up instead of down.