is there a repository for Free Assets?

[mdtrooper]

Hi.

Yesterday, I see the awesome news about there is a Linux native version.

And now I wonder about the repository for Free Assets, I want to help it.

Because the brother project (OpenTTD) have free assets, and they are called as NewGRF, OpenSFX and OpenMSX.....I imagine a complete free OpenRCT2 (and I love it ;) ).

Regards.

[wolfreak99]

Right now the project is still heavily tied to the original assemblies, thus the sprites are still tied from the internal files. There hasn't been any sprite rips as of yet (at least that i know of), and i assume that would be the first step to getting redrawn versions (that way the know what all needs drawn). The only "assets" that exist so far (at least that i know of) would be on https://openrct.net/ , along with various other general rct content hosting sites

[Krutonium]

We rely on the originals, yes, but there are resources online that explain how to make new stuff for the game - so we could already have people making new resources.

[janisozaur]

If (or should I say – when) we got to the point where we can use our own assets (possilby using our own format), I'd imagine them to be zBase-like, by which I mean they would have the master files with 3d object modelled and only exported to static 2d with a script

[IntelOrca]

@wolfreak99 trigger-death made a sprite ripping program which also works for RCT1.

We can't yet render 32-bit graphics, but if we were to replace the graphics it would be full 32 bit recreations of all the original sprites. Like @janisozaur said, the rides and objects would be 3D models rendered as 2D isometric just like the original graphics were - only we do it in 32 bit.

Problem is there is a huge number of sprites, it would take a long time for several very committed artists to do the lot consistently. The interface graphics would be the first ones to be done.

[duncanspumpkin]

For the interface graphics if people want to get started on them that would be great. We would ideally want them to be scaleable since thats one of the problems with the existing graphics. At some point someone will have to sit down and start specing out exactly how we want the new graphics to be done.

[HaasJona]

For tracks and similar things we could probably reduce the workload by creating the models using scripting. For example define the cross-section, materials and the general support structure somewhere and then let it auto-create all the various slope and turn models.

[mdtrooper]

@duncanspumpkin Well, it is sounds great. I want to start with the interface graphics. I am good with Inkscape.

I have been searching for the tool to ripper the sprite...but I didn't find it. What is the name or url?

[duncanspumpkin]

@HaasJona that's what @X123M3-256 s ride maker already does he would be the best person to help with that. I need to finish the drawing functions as he was getting a bit stuck on what images are required to replace tracks and we won't know for sure until the functions are finished. @mdtrooper http://trigger-death.github.io/RCT2Tools/GraphicsExtractor/ is the g1 extractor. As said, before you start making things we need to have at least a little think about what we want. And how we are going to integrate the new graphics.

[IntelOrca]

Yes, re-creating graphics is difficult if the majority of people are to be happy with the results. They can't be too cartoony or too realistic or too smooth - they have to match the art style as close as possible to the original game but still re-imagined in 32-bit and at at least 4x bigger.

[pizza2004]

I think the interface graphics should be vector so that they can easily scale to be roughly any size on any display the game might encounter. The rest of the graphics logically could still be raster though. It would strike a nice balance. Personally I'm still hoping that person who said we might be able to get the original models to work with is right.

[IntelOrca]

The graphics can be made using vectors but they will need to be rasterised to some size for the game, we aren't going to implement any kind of SVG drawing in the game - that would be overkill.

[X123M3-256]

I know this thread is a few days old by now but I've got a couple questions to add as I've been interested in the possibility of replacement graphics for a while now.

@IntelOrca, you said you want the replacement graphics to be 32bpp. I assume that means we can't create replacement graphics yet, as the game at present uses a custom image format that only allows for 256 color graphics. There's also heavy use of palette swapping for effects like water, glass, and recolorable objects. It seems to me that this sort of stuff can't be changed until the dependency on rct2.exe is lost, am I correct?

@HaasJona I had a similar idea about tracks, and I have an early prototype of such a track renderer, the results of which can be seen here. The main difficulty is in determining how the track sections are split up into seperate sprites - I originally thought it was one sprite per tile but this turns out not to be the case - more investigation will be needed to get this ready for actual use.

I've carried out a couple of experiments with rendering new terrain sprites as well, which I don't currently have any screenshots of. I was able to get a close visual match to the game's tiles, but the shading was a bit off because I had trouble getting Blender's lighting to match the games. I tried again with my own renderer - the result was that the shading matches, but the tiles themselves looked awful because my renderer does not have support for textures or normal mapping yet.

Is the goal to get as close to the original sprites as possible, or would it be OK to alter things like the lighting parameters? (mostly because the original lighting parameters are hard to determine because I don't know what lighting model was used and there's a lot of variables to account for). Does anybody actually want replacement graphics at this stage of development? I could probably make an attempt at doing this because I've been working on some tools for creating custom rides that could be repurposed to target the base graphics instead.

[duncanspumpkin]

@X123M3-256 i think if we can bash out some plans for the graphics there is no reason why we can't start doing them right now (lighting model could be decided and such). As long as we keep the original model files until we are completely decided we can always change ideas.

I think now almost all of the graphics (apart from dithered images used for terrain)are drawn using the openRCT2 code so there is no reason why we couldn't start using new assets. It would have to be direct same sprite id dropins right now as the paint setup code is not finished. I don't know what we would do for the palette swaps that will require some thinking.

[IntelOrca]

@X123M3-256 We could probably get 32bit graphics working already as we have implemented all the actual blitting functions - but there are more important things to do right now than that. It would also require a new image format and a new object format for object graphics. So some day, but not today.

As for lighting model, I guess we would try to get it close as possible to the original game, but its probably more important that the lighting is consistent across all objects rather than accurate to the original game.

There are likely to be things which have more that one sprite per tile, mainly for things to be drawn behind and in front of other objects. For example tunnels or doorways where vehicles or peeps must walk in-between two sprites on the same tile.

[X123M3-256]

@IntelOrca The lighting model comment was mainly because it's really hard to determine the original game's lighting model. I've tried to get the correlation between palette indices and luminosity, and that's what my renderer is based on right now, but it's really hard to get it pixel-perfect.

I know there are things that have more than one sprite per tile - I've already got code that can handle that automatically by transforming the splitting plane into screen space and selectively discarding pixels that fall on the wrong side of it. This can be done easily for sprites rendered in my renderer, but it's tricky for sprites imported from other sources as you need the z-buffer. I think blender has the option to export that as well though. The real challenge is with track sprites, which are split, but not necessarily along tile boundaries. inthemanual thought they were split in screen space and I think he might be right, but I didn't look much further than that. As long as I can work out how the sprites are split it should be possible to write code to handle it.

@duncanspumpkin What I was thinking is that it's possible to create new assets in the same format that RCT2 uses so the code itself wouldn't need changing immediately. I've done experiments modifying g1.dat but there's a bug in my code somewhere still as doing so causes glitches when zoomed out. Most of the work is in creating the models, and determining how the sprites should be split - once that's done it would be fairly easy to render another set of sprites from the models if there was a desire to support true color or greater resolutions, or change the file format.

I think I could probably write tools to handle efficient generation of terrain, track, and possibly support sprites. The other major one is peep sprites, but the complexity of the animations might make that one of the hardest to do. Interface sprites have few patterns and will probably have to be done by hand.

Is this something that's worth attempting right now, or would it be better to wait until development is a bit further along?

[IntelOrca]

Well priority is:

1. Bug fixes
2. Reverse engineering
3. Cross platform
4. Refactoring

This would be considered an extra feature. But if you can't do any of the things above or simply don't want to then there is no harm in progressing with this side project. I just probably won't dedicate any time to writing new rendering code until after everything is decompiled.

[X123M3-256]

OK. I'll leave this project until another time then. I might look at working on the reverse engineering but I didn't get very far last time. Maybe I'd have more success now that it's a bit further along - at least I know what functions I'm looking for now.