Project Carrot homepage
GitHub: Project Carrot · PCAE · PCTC · PCLC

Current project status (1/2017): Semi-active
Slowly progressing, but also putting quite a bit of time into other things. Such as AGDQ'17

Good to see my million years old account still works

I've been writing a JJ2 engine clone, titled Project Carrot for now, since this February. The plan is, of course, emulate the whole game without losing compatibility to old levels and tilesets while adding new features (like you can already have as many foreground and background layers as you want to). There are though some secondary features I have already decided to drop such as Caption tiles (likely to cause a lot of extra headache for little profit) and level password protection (source code being eventually open source would render any kind of protection useless because user could just check how the game decrypts the data for its own use).

I decided against announcing the project here immediately back then as I'm painfully aware how game development by casuals works most of the time: announce a project, work on it for a week, forget it till eternity. So I've been holding this back for quite a while now, but as I'm still three months later still working on it, I thought it'd be great to show it off a bit.

I recorded a short-ish overview of the current state of the engine and put it on YouTube. You can see it here. The second preview video was recorded in October 2013 and is available here, and the third video from May 2016 is likewise here.

See the newest additions from the git commit history in the repository.

----

Once I feel the code is complete enough, the game will be available for download and the source code will be made public (I'll put it on git or something) it already is. Or if I decide to scrap it, the source code will still be published. Until then, you'll just need to wait (I have so many personal projects that don't expect anything completely implementing all of Jazz2 for a year or two at least.)

So, yeah. Any thoughts, ideas I should record for later, etc.?

E: And of course, I need to express my gratitude to everyone who has been involved with taking apart the proprietary formats during the many years after the game was released. Making this would be a thousandfold harder without all the knowledge floating around

Well, I'm sold! Some initial thoughts:

• The framerate, and the turtles' movement in particular, looks a bit slow. Is this an artifact of running recording software?
• The layer speeds look accurate, though it's harder to tell for non-standard resolutions. I notice layer 8 is also moving, which makes total sense, but is also some sort of statement about how you view emulation. Or just something you haven't cared enough to change yet, whichever.
• I noticed an "Actors" count, which would appear to be the number of active objects, since it increases when you shoot a bullet and decreases when you collect a pickup or shoot an enemy. I also noticed that it's totally global and counts all the active objects anywhere in the level. Obviously this is a work in progress, but I might as well ask sooner rather than later: you know that's not how Single Player works?
• "I haven't yet extracted the animation for [shooting while hanging] nor specified the ammo starting point." But they're in anims.j2a in the exact same place as Jazz's other animations, and internally specify their "ammo starting point" in the exact same way as Jazz's other animations. What's the problem here? Are you not reading the .j2a file?
• What's with the weird converting .j2l and .j2t files into other formats thing? Wouldn't it be easier for everyone to be able to play them directly?
• What are you basing your code on, physics and animation code in particular? Careful observations of JJ2 in action, or a disassembly of the executable, or what?

This looks very promising.

Thank you for the kind thoughts and feedback

Originally Posted by Violet CLM

"I haven't yet extracted the animation for [shooting while hanging] nor specified the ammo starting point." But they're in anims.j2a in the exact same place as Jazz's other animations, and internally specify their "ammo starting point" in the exact same way as Jazz's other animations. What's the problem here? Are you not reading the .j2a file?

I am indeed not reading the .j2a file but instead specifying hard coded filenames coupled with fixed center points and FPSes from inside the code. That will probably change later, though, for both structural and legal reasons.

Originally Posted by Violet CLM

The framerate, and the turtles' movement in particular, looks a bit slow. Is this an artifact of running recording software?

Some of the speed differences come indeed from recording software which both slows down drawing a bit and can only record at max. 30FPS itself. It might be that I have typed an incorrect FPS for the turtle walk animation as well.

Originally Posted by Violet CLM

The layer speeds look accurate, though it's harder to tell for non-standard resolutions. I notice layer 8 is also moving, which makes total sense, but is also some sort of statement about how you view emulation. Or just something you haven't cared enough to change yet, whichever.

I can see what you mean; I didn't play around with JJ2 to notice this. Castle1.j2l seems to have non-zero speeds on layer 8 and I am just blindly using those At the same time it is a feature as you can define a speed to it just like any other layer (except sprite layer). A proper solution to this would probably be to ignore Layer 8 speeds at the conversion phase. The sky layer in Carrotus should not be moving in the video though, I'll need to double check that

Originally Posted by Violet CLM

What's with the weird converting .j2l and .j2t files into other formats thing? Wouldn't it be easier for everyone to be able to play them directly?

That is also temporary at least to some degree. Not sure how it will be done later on, other than that players will not need to tinker around with command line tools later on

Originally Posted by Violet CLM

I noticed an "Actors" count, which would appear to be the number of active objects, since it increases when you shoot a bullet and decreases when you collect a pickup or shoot an enemy. I also noticed that it's totally global and counts all the active objects anywhere in the level. Obviously this is a work in progress, but I might as well ask sooner rather than later: you know that's not how Single Player works?

I haven't done too much research on that; the only effect actors have when they are not in the field of vision is that they don't try to draw themselves off-screen. If there's anything crucial I need to know here, do tell

Originally Posted by Violet CLM

What are you basing your code on, physics and animation code in particular? Careful observations of JJ2 in action, or a disassembly of the executable, or what?

Only personal observations. That means the physics might be off here and there.

Originally Posted by UltimateSephiroth

I can see what you mean; I didn't play around with JJ2 to notice this. Castle1.j2l seems to have non-zero speeds on layer 8 and I am just blindly using those At the same time it is a feature as you can define a speed to it just like any other layer (except sprite layer). A proper solution to this would probably be to ignore Layer 8 speeds at the conversion phase.

It's basically a bug in the original. They wanted layer 8 to snap to the upper left corner of the screen at all times when xSpeed=0 and ySpeed=0, which isn't how other layers work, in order to make backgrounds look better, but then they took that too far and made it true even if the speeds aren't zero. As a result, there isn't really a right way to treat layer 8 speeds, so much as there are various different statements it's possible to make by treating them one way or another.

I haven't done too much research on that; the only effect actors have when they are not in the field of vision is that they don't try to draw themselves off-screen. If there's anything crucial I need to know here, do tell

Broadly speaking, in local play single player, objects more than about 32 tiles away from the player will be deleted from the active object list. There are a handful of exceptions -- rotating rocks in particular are never deleted -- but for the most part that's how it works. It's supposed to be a memory/speed-saving measure, but it does end up having various side effects, positive and negative, for real gameplay and level design. (For example: without it, all swinging vines are synced with one another.)

Originally Posted by Violet CLM

It's basically a bug in the original. They wanted layer 8 to snap to the upper left corner of the screen at all times when xSpeed=0 and ySpeed=0, which isn't how other layers work, in order to make backgrounds look better, but then they took that too far and made it true even if the speeds aren't zero. As a result, there isn't really a right way to treat layer 8 speeds, so much as there are various different statements it's possible to make by treating them one way or another.

Ah, I see Also, you have stated another difference in my implementation just now: any layer with zero speeds is treated equally in PC. I set Layer 3 to zeros in JJ2 and tested it, from what I gathered it just disappeared, so I guess not mimicing that wouldn't really hurt.

Originally Posted by Violet CLM

Broadly speaking, in local play single player, objects more than about 32 tiles away from the player will be deleted from the active object list. There are a handful of exceptions -- rotating rocks in particular are never deleted -- but for the most part that's how it works. It's supposed to be a memory/speed-saving measure, but it does end up having various side effects, positive and negative, for real gameplay and level design. (For example: without it, all swinging vines are synced with one another.)

Performance was the first thing I thought of, but if it indeed affects other things too, then I suppose I should do something about it. Just not running their tick events would work otherwise but I launched JJ2 and I can see they also lose whatever changes they were affected to (gems shot down are floating again) so I guess I'll need to think into this a bit more.

Originally Posted by cooba

I remember you!

Ha, just noticed that How's that possible when I barely posted any posts here or even logged in for four years (according to what "you last visited" told me, anyway)?
E: Oh, it seems we had a PM conversation back then at least. God, I can't stand to look at my posts, my English was so simple back then

Zero speed layers are used from time to time for HUDish effects... look at e.g. Tomb Rabbit or Another Story, though those naturally assume a 640x480 resolution.

Here's what deactivating does, using some very verbose names:

object.pointerToBehaviorFunction = NULL;
//The object is no longer is counted as active,
and its location in memory may be overwritten at any later time.
if (object.wasCreatedDirectlyFromTheLayer4EventMap()) {
    eventMap[object.xTileOfCreation, object.yTileOfCreation] = object.eventID;
    //e.g. 158 for a peach, whatever. For the most part this is
    //redundant, but it does mean that when an object created
    //directly from the event map changes event ID, e.g. a spring
    //crate changing into a green spring, that change will be
    //permanent even if the object is later deactivated.
    setEventMapBit(object.xTileOfCreation, object.yTileOfCreation, 11, false);
    //The event map, of course, is a series of thirty-two bit slots
    //for each tile in layer 4. The first eight bits are used for the
    //event ID. The next three are used for the difficulty and the
    //"Illuminate Surroundings" checkbox. The bit after that is
    //whether the the object created by the event at that tile
    //has already been created or not: setting it to false tells JJ2
    //that the next time that tile comes into active memory, the
    //object should be created, since it hasn't been created already.
}

I watched your YouTube video and like what you did so far. I'm not into coding, nor do I know how JJ2's physics work. But I can only encourage progress on projects such as this. A remake of JJ2 such as OpenJazz is for JJ1 would make dreams come true and stuff like that.

Perhaps consider talking to DJazz on these forums? And read through some of his findings he wrote on his WebJJ2 thread. I'm sure he has some interesting solutions on JJ2's physics that're reade to use!

Originally Posted by Violet CLM

Zero speed layers are used from time to time for HUDish effects... look at e.g. Tomb Rabbit or Another Story, though those naturally assume a 640x480 resolution.

Hmm, I see, I'll need to look into those levels then. Can't do it right now as I traveled elsewhere for Mothers' Day and JJ2 doesn't apparently want to cooperate with Windows 8 on my lappy, but will do so on Monday.

E: I looked at the first level and I can see how it works, but now I need to understand why it works that way

Originally Posted by Violet CLM

Here's what deactivating does, using some very verbose names:

object.pointerToBehaviorFunction = NULL;
//The object is no longer is counted as active,
and its location in memory may be overwritten at any later time.
if (object.wasCreatedDirectlyFromTheLayer4EventMap()) {
    eventMap[object.xTileOfCreation, object.yTileOfCreation] = object.eventID;
    //e.g. 158 for a peach, whatever. For the most part this is
    //redundant, but it does mean that when an object created
    //directly from the event map changes event ID, e.g. a spring
    //crate changing into a green spring, that change will be
    //permanent even if the object is later deactivated.
    setEventMapBit(object.xTileOfCreation, object.yTileOfCreation, 11, false);
    //The event map, of course, is a series of thirty-two bit slots
    //for each tile in layer 4. The first eight bits are used for the
    //event ID. The next three are used for the difficulty and the
    //"Illuminate Surroundings" checkbox. The bit after that is
    //whether the the object created by the event at that tile
    //has already been created or not: setting it to false tells JJ2
    //that the next time that tile comes into active memory, the
    //object should be created, since it hasn't been created already.
}

That makes sense. I don't actually even store the event IDs currently anywhere after the objects have been spawned but doing something like this would make simulating the effect easier. (Also storing the event IDs and all would kinda make emulating MCEs easier; I'm kinda on the fence with them in that they allow for some special stuff not otherwise possible, but at the same time are essentially a large scale bug and not really a feature.)

E: (De)activation routines have been implemented.

Originally Posted by Slaz

I watched your YouTube video and like what you did so far. I'm not into coding, nor do I know how JJ2's physics work. But I can only encourage progress on projects such as this. A remake of JJ2 such as OpenJazz is for JJ1 would make dreams come true and stuff like that.

Perhaps consider talking to DJazz on these forums? And read through some of his findings he wrote on his WebJJ2 thread. I'm sure he has some interesting solutions on JJ2's physics that're reade to use!

Thanks Yeah, I checked some threads involving him, I suppose he could have useful information and insight on some aspects

It's nice to see someone working on a jazz jackrabbit game. But like you said most projects have died so far. So far your video shows you've made quite some progress, so i hope you don't give up where others did! If you do succeed i also hope this can help to attract more players to jj2. But untill then, keep up the good work

Keep it going! I Love this project to be finished.

I Have some questions...
It would support more colours at the tilesets? We now living at modern world and 8 bit colours are NOT ENOUGH!

It would possible to expand the tiles 1024 (4096 for TSF) limit? It looks too small and I love mixing 2 or more tilesets on 1 tileset.

Originally Posted by Foly

It's nice to see someone working on a jazz jackrabbit game. But like you said most projects have died so far. So far your video shows you've made quite some progress, so i hope you don't give up where others did! If you do succeed i also hope this can help to attract more players to jj2. But untill then, keep up the good work

Thank you I'm not planning to give up so don't worry

Originally Posted by RedComputer

Keep it going! I Love this project to be finished.

I Have some questions...
It would support more colours at the tilesets? We now living at modern world and 8 bit colours are NOT ENOUGH!

It would possible to expand the tiles 1024 (4096 for TSF) limit? It looks too small and I love mixing 2 or more tilesets on 1 tileset.

I guess I have good news for you

Essentially, all the tileset conversion process shown in the video does is that it generates two PNG images: one for the tiles and one for the mask. Naturally, an original tileset can thus be made using PNG images as well. Since PC runs in full colour, there are no restrictions on available colours (and while I haven't tested it with anything else but fully opaque and transparent, other alpha channel transparency values should be supported out of the box as well). The mask image meanwhile works sort of like binary collision map (white or any pixel with full transparency is unmasked, everything else is masked). Tilesets are also not confined to being 10 tiles wide anymore; how this will be handled in the to-be level editor is yet to be seen.

The tile amount limit isn't nearly as strict anymore either. In theory, only the tileset image dimensions themselves limit the available number of tiles; the current temporary layer format I'm using allows up to 65536 static (first one still reserved for empty tile) and 65536 animated tiles, but that could be upped. Though, there's currently a yet unsolved graphics memory issue related to how SFML handles textures; i.e. large tilesets currently will fail to load on cheap GPUs because the image won't fit to a single texture vertically in their video memory. But if that is solved, then the max. tile amount can be raised significantly.

Wow, that is awesome! I mean, it's awesome anyway, but what you just said made it even more awesome(I would point out all the good things about the PNG format and RGB/Alpha, but anyone who doesn't know what all this means can just google it).
By the way, do you think it will be possible to have a high-resolution/HD mode, which would have double-sized sprites(Perhaps it could include an "animsHD.j2a" file, or something?), and allow tilesets with double-sized tiles?

I... might sound somewhat harsh. I admit I dislike it when people admire another community member for creating another level previewer, again. Hopefully you realize this thing here is little more than a level previewer. Collision detection is no philosophy and everything else will have to be completely rewritten later on if you want it to work like JJ2. So yeah, I consider it hard to be excited about this so far and I'm just bothered by apparent lack of common sense in this thread, no offense to anybody.

I know this is not quite a constructive message and I was holding myself back from posting it until now. I'll try to compensate it with an honest offer to help; I consider myself familiar with a good number of quirks of JJ2, most of which you should learn if you want to replicate its mechanics correctly. Also, although you're obviously not coding the game in it, judging by your signature you may be interested in a piece of GML code I'm coincidentally in possession of that draws what pictured below, if just for reference. Use PMs.

Oh come on, it's clearly further along than any "level previewer" we've seen so far. There's item pickup, animations, lots of working events (vines, ammo, hurt), enemies, more-or-less accurate physics (you can shoot down items), sound effects, running/jumping/buttstomping... It's obviously not complete yet, but there's a substantial amount of gameplay implemented already, in a way that seems to mimic JJ2 fairly well so far.

I saw the above posts in this thread. I'm think this game or whatelse is promising but is a good idea the high color (16-bit) or true color (32-bit) and higher tilesets. I wish good luck for developing.

If you say so, Stijn. I just believe most of the presented features that aren't necessary for a level previewer to be a matter of one weekend, but what do I know.

Originally Posted by Sir Ementaler

If you say so, Stijn. I just believe most of the presented features that aren't necessary for a level previewer to be a matter of one weekend, but what do I know.

Wow, you convinced me, I no longer care about this primitive and plebeian level previewer

I didn't have a whole weekend.

Originally Posted by Sir Ementaler

If you say so, Stijn. I just believe most of the presented features that aren't necessary for a level previewer to be a matter of one weekend, but what do I know.

Looks a lot less complete than what UltimateSepiroth showed, to me.

Ether way, when does something stop being a "level previewer" and start being a "game engine"? Allowing you to navigate a level is a pretty big part of the game, after all.

guys this is the STUPIDEST FIGHT

you BOTH are good at doing stuff and have promising projects should you care to continue developing them and we're proud of BOTH OF YOU and it's perfectly all right to have competing projects (I've done one! I think I kinda lost.) without being NASTY about it

don't make me call this a bunny game, the JCF censors it so it's kind of difficult to do so

Oh, thanks Violet, but to be honest I'm not developing anything and really don't intend to fight. Just took my own level previewer and added events and physics to it once Stijn mentioned this being more advanced. Then it took me the night to upload it to YT.

Originally Posted by Sir Ementaler

I... might sound somewhat harsh. I admit I dislike it when people admire another community member for creating another level previewer, again. Hopefully you realize this thing here is little more than a level previewer. Collision detection is no philosophy and everything else will have to be completely rewritten later on if you want it to work like JJ2. So yeah, I consider it hard to be excited about this so far and I'm just bothered by apparent lack of common sense in this thread, no offense to anybody.

I know this is not quite a constructive message and I was holding myself back from posting it until now. I'll try to compensate it with an honest offer to help; I consider myself familiar with a good number of quirks of JJ2, most of which you should learn if you want to replicate its mechanics correctly. Also, although you're obviously not coding the game in it, judging by your signature you may be interested in a piece of GML code I'm coincidentally in possession of that draws what pictured below, if just for reference. Use PMs.

Point taken, though I honestly don't know what you expected this thread to contain I'm not here to show off a completed game but a prototype. I'm not very sure what you mean by the rewriting point either - while I am going after the mechanics of the JJ2 engine, I am certainly not rewriting a JJ2 engine on structural or any other level. The "correctness" of mechanics isn't completely black and white; what is a bug to one might be a feature to someone else. While I strive to replicate the game behavior closely, I won't be throwing deliberate mistakes or unnecessarily complicated special cases into my code just to make it a 100% clone.

I expect the demo you just put up there was also written in GML; bear in mind that Game Maker provides the whole framework for handling sprites, drawing and different events built-in, while I've built my own engine that implements most of that stuff from the ground up all by myself. The way objects are handled in GML (basically almost nonexistent encapsulation) and preferred use of globals also simplifies things a lot.

Of course I could've started writing this in some game-centric engine like Game Maker or Stencyl but I wanted to use a more mainstream language to 1) learn C++ better, 2) make it easier for, erm, people with a better mindset to contribute later on, 3) not be too environment dependent (Qt, SFML, BASS all should work just fine in both Win, Mac and Linux). So, because of that decision, I'm required to write a lot more code that is specific to the engine but not necessarily the JJ2 experience. The TileMap class, which contains pretty much all tileset and layer handling (i.e. the core part of what would be a level previewer), doesn't even cover a fifth of the codebase

As for the textured background algorithm, I might be interested later; implementing it now is not a high priority so I'll PM you when it becomes topical (unless I decide to write it myself).

Originally Posted by Violet CLM

guys this is the STUPIDEST FIGHT

you BOTH are good at doing stuff and have promising projects should you care to continue developing them and we're proud of BOTH OF YOU and it's perfectly all right to have competing projects (I've done one! I think I kinda lost.) without being NASTY about it

don't make me call this a bunny game, the JCF censors it so it's kind of difficult to do so

I'm not much into fighting either, and I don't think I've been fighting at all at this point yet I also don't have any problem if someone else decides to start a separate project; if anything, that shows JJ2 still has enough appeal for multiple projects to appear.



As for the lack of new bullet points under the link in the OP, I've been busy with the exams for the last two weeks but I hope to get back into writing code next week (Though pauses in general shouldn't be taken as signs of abandonment, I do have other things in my life going on as well )

keep up the attitude and don't give up
this could be big

Originally Posted by Soulweaver

Point taken, though I honestly don't know what you expected this thread to contain I'm not here to show off a completed game but a prototype.

I expected it to contain less exaggerated reactions, everything else is fine.

Originally Posted by Soulweaver

I expect the demo you just put up there was also written in GML; bear in mind that Game Maker provides the whole framework for handling sprites, drawing and different events built-in, while I've built my own engine that implements most of that stuff from the ground up all by myself. The way objects are handled in GML (basically almost nonexistent encapsulation) and preferred use of globals also simplifies things a lot.

Yes, although you must realize simplifying things doesn't always make them easier to use. And large portions of C++ code for drawing sprites, collision detection etc., can be successfully copied from older projects, assuming you had any. If I had had a ready level previewer in C++, I'd have used that to record the demo instead, but all I had at that moment was a GML one, so I used that.

Originally Posted by Soulweaver

Of course I could've started writing this in some game-centric engine like Game Maker or Stencyl but I wanted to use a more mainstream language

God bless you.

Do you plan for another video?
EDIT: What program do you use for the buttons on the title bar?

Originally Posted by RedComputer

Do you plan for another video?
EDIT: What program do you use for the buttons on the title bar?

Eventually, when there's actually enough new stuff to show I got a bit sidetracked with playing several visual novels (Rewrite, Steins;Gate, Muv-Luv) recently, so I haven't been working on Project Carrot too much, but rest assured I haven't forgotten about this at all.

The title button software I'm using is Actual Title Buttons.

Originally Posted by Robo4900

Wow, that is awesome! I mean, it's awesome anyway, but what you just said made it even more awesome(I would point out all the good things about the PNG format and RGB/Alpha, but anyone who doesn't know what all this means can just google it).
By the way, do you think it will be possible to have a high-resolution/HD mode, which would have double-sized sprites(Perhaps it could include an "animsHD.j2a" file, or something?), and allow tilesets with double-sized tiles?

I just noticed I completely missed this post earlier, so better late than never. A HD mode could be a nice feature, but while I won't say that won't happen, implementing such mode is not a high priority at the moment.

Originally Posted by Sir Ementaler

Yes, although you must realize simplifying things doesn't always make them easier to use. And large portions of C++ code for drawing sprites, collision detection etc., can be successfully copied from older projects, assuming you had any. If I had had a ready level previewer in C++, I'd have used that to record the demo instead, but all I had at that moment was a GML one, so I used that.

Late response to this as well. Yes, I'm well aware. For instance, I struggled to make proper looking menus back when I actively used GM; they always ended up looking simple or awkward and utilized way too many objects. As for code snippets, I guess that's true, though I don't really have any

Remembering how I wanted to make the JJ2 clone same way you did
The tileset would have the simular format but they are on zip file instead normal folder.

Do you add support for Palette just for the GUI and sprites?

Originally Posted by RedComputer

Remembering how I wanted to make the JJ2 clone same way you did
The tileset would have the simular format but they are on zip file instead normal folder.

Do you add support for Palette just for the GUI and sprites?

To be honest, I haven't really put much effort into solving the problems related to not using palette based graphics (SFML handles it all as 24-bit color + 8-bit alpha), though the only place where I currently remember palette based graphics being vital is multiplayer with its character sprites. I cannot say much at this point, but it's very likely there won't be much palette functionality in the end.

Packed level and tileset support is something I've looked into but haven't worked on yet at all; the actual format will stay as a folder with multiple files, but for distribution a single file approach is much nicer.

Keep working on the project and don't stop until it's finished (please). Just post at least once a month for the community to know you are still there.

Originally Posted by dOLDIZ

Keep working on the project and don't stop until it's finished (please). Just post at least once a month for the community to know you are still there.

I visit the forum at least once a week and post either if someone asks something or if I make progress warranting a new reply instead of a new item in the first post, so I guess that's enough. Speaking of progress, there hasn't been any and I know it doesn't look very promising; I have a bit of trouble trying to do everything I have under way, and programming has probably suffered the worst. Regardless of the slow pace, I'm not quitting

I actually put together last month a narrated short video about the changes I've listed in the first post but never uploaded it since I came to the conclusion that I can't talk English spontaneously at all. Maybe I'll try again later or just scrap the narration.

Any news?

Relax, it hasn't even been a month since the last time he posted

Originally Posted by RedComputer

Any news?

Nothing more than what's written on the first post; as said in the previous post, having trouble fitting everything on my schedule currently, hoping it'll turn out better later on.

http://www.youtube.com/watch?v=_uFeWwbaKcg

I posted a new video on YouTube showing all (or at least most of) the new tiny bits of code added since the last video in May. As said, I would've hoped to get more done in five months, but at least the project isn't dead

Awesome! I'm sure we will all be excited the day you put it public!

Impressive! Excited to see where this goes next.

This looks so much like the original Jazz2! Absolutely amazing work. Keep doing this please!

I guess you've already read my YouTube commenting, but keep up the good work. I honestly didn't expect such a project to last this long!

Originally Posted by Slaz

I honestly didn't expect such a project to last this long!

Indeed, after pretty much all the previous projects we have seen got abandoned. So it's really quite a relief to see progress reports like this! All is looking very promising