I have been a fan of TH for ever, and would love to help get CorsixTH its own free graphics set... I would also be really keen on making new features like new diseases/treatments/rooms possible... But I need a bit of help to get started!

1. Is there a sprite browser, and how do I use it? Even better are there any sprite sheets which can be downloaded?2. What format do the original graphics use? Is it 8 bit paletted images? Or 32bit images? Do things like sprite recolouring happen?

With that info I can get to work... I genuinely think a complete graphics replacement is an achievable project, after all I managed to make zBase in 3 months.

Bundled with CorsixTH is a small programme AnimView or something like that.

When you open it you are prompted with two choices, you then have to point to where you have the original files for TH.You can view the animations or you can now export them to see the individual frames - takes about twenty minutes or so to do the export.If you get into any difficulties you can usually find someone in IRC

Hi! I do recognize your name, I was following the graphics replacement project at OpenTTD until a year ago or so. :-) Very good work you have done there! We would of course love to get help from you here too.

As Mark says the Anim Viewer bundled with the Windows Installer (or compilable from source of course) is the way to view sprites and export them into pngs. When it comes to getting new graphics into the game again we're just now working on implementing the backend to support it.

1. Is there a sprite browser, and how do I use it? Even better are there any sprite sheets which can be downloaded?

No sprite sheets afaik, I once tried to rip them out of the data loader, but had trouble with the palettes.Later I found that RGB colours in the palette are 6 bits only, which is widened to 8bit triplets during loading.

This evening I found DATA/MPALETTE.DAT which may be the palette of the main display.

I may try that again.

Quote from: Zephyris

2. What format do the original graphics use? Is it 8 bit paletted images? Or 32bit images? Do things like sprite recolouring happen?

8bpp, for each screen (eg hospital display, bank manager, drug case book, graphs, etc). In the original game these were full screen, which is why they have their own palette. in Corsix-th, the "full screen dialogs" are not full screen anymore, they are just a significant part of the screen.

At least the SDL back-end (and probably also the other back-ends) renders in 32bpp. This enables display of the hospital and a 'full screen dialog' at the same time. Also, stuff like warmth colours in the map are 32bpp colours blitted into the video display.

Not sure whether recolouring is happening. In the file format description they do mention it, so it's possible.What is certainly done is 'morphing', where two sprites are partly drawn, eg at the pharmacy, when an patient is drinking a potion. There is also a 50% and 75% transparent flag, as well as a flip-horizontal and flip-vertical flags.

This may be a stupid question, but how do you use the sprite/animation viewer? The sprite viewer doesn't let me scroll through or export the sprites, and the animation viewer doesn't seem to be able to load any data whosoever! I feel I must be doing something stupid...

*edit* It seems I'm using an older version, were these issues updated at some point?

*edit2* Ah. Ok. So the animation browser doesn't need to be directed to the animations folder

Finally got all the sprites exported! Overall a complete graphics replacement looks pretty manageable. Here's how I see it breaking down:1. GUI: MONEY01V, MPOINTER, PANEL02V, PANEL04V, PULLDV, WATCH01V. 156 sprites.These are probably the simplest to redraw, but also the ones where there is most potential future desire for alteration to make things like translation or GUI modification easier. Pixel art certainly seems to be the way forward for these ones. As these are a separate 'module' of graphics which are not integral to the rest of the game I probably won't touch these ones yet.

2. Environment: VBLK-0. 222 sprites.These environment sprites are the basic ground tiles, walls and outside objects. The biggest chalenge here (and it is not a big challenge) is making sure everything tesselates correctly. I would again err towards pixel graphics, to keep the tesselation working well, possibly layered with 3D renderings for the objects which decorate outside tiles.

3. Objects: VSPR-0. ~500 sprites?The main set of sprites can be broken into two halves; people and objects. The two interact a lot though! Many of these are static objects which would be simple to make by 3D rendering. I would err towards simulating a pixel graphics style though, i.e. no anti aliasing, high contrast, and dark 1px outlines, to match with the style of the people graphics.

4. People: VSPR-0. ~2500 sprites?These will certainly be the hardest to draw mostly because standard body sprites are reused and layered with different head, animation and injury sprites. These I think will be vastly easier to draw as pixel graphics to keep the same body/head alignments...

There is one remaining major technical question: All the sprites have particular sizes and (presumably) alignments. Is there any way to modify the expected size and alignment to assist getting them into the game? Or is it better to copy size and alignment when redrawing?

1. In the early stages of defining dialogs in Lua the easiest way to go was to simply input the exact dimensions of each object, and that has since survived for all dialogs. This means that if we change sizes of any GUI sprites their Lua code will also need to be changed. The obvious way to go is to instead let the game measure the actual image, but that will require us to introduce some layout manager and will require quite a lot of work. Therefore I vote for going with the same relative dimensions for the time being. However, a feature we really need soon is the ability to scale the GUI since more and more people have very high resolutions. With that in mind I suggest drawing the GUI somewhat larger, just keeping the aspect ratio of each image.

2, 3, 4. A good separation. :-) I agree with all your comments.

While the game does not directly depend on the exact size of one particular in-game sprite it does when building compound animations rely on that the content of each sprite is aligned the same way within the image. So I suggest that we keep them too as they look right now.

Maybe you could try drawing one or two objects, then Alberth could see if they work out in-game and if he needs to change anything in the new code. Then I can fix the Lua part to be less hard coded (as Alberth has stated in the issue at google code). Just to make sure that you don't do too much that we can't use in the end.

Hello fellows! I'm greenpower from the corsix-th IRC channel. As some of you might now I volunteered to do some replacement graphics for this lovely game. Because I don't want to see people doing the same work twice we shall unite forces and get some kind of "agreement" or "schedule" to be sure we don't do the same thing twice. My modeling skills are a bit bland but I can improve and people from the IRC channel seem happy with my work. If you want to get an idea of what I'm doing visit my photobucket account and zoom through some of my development pics: http://dft.ba/-CorsixTH_GFX12

I'm glad to know that I'm not the only one and I'm eager to see what we could achieve both of us.

Seems to look quite nice. Was the graphics for the blueprint changed too? In that case, are they too similar? Zephyris, you probably know best how close we can be to the original without being too close?

If you study the road tiles you will see that s45 and s46 are the same and there is no opposite to s53, which is how they are in the game now.We could do with losing the duplicate and getting the missing one imo.