OpenGFX - Graphics Base Set

[planetmaker]

@edorfaus: The re-worked upside-down cone looks indeed much better to me.

I do agree, they now look much better . I implemented them in OpenGFX r142:

toyland trees

Anderburg Transport, 21-04-1980.png (70.3 KiB) Viewed 5848 times

And while I'm at it:

ingame image with statue

new_statue.png (47.81 KiB) Viewed 5844 times

[Roujin]

That looks indeed much more like it has depth... but what's the stuff behind the figure's head? Can't make anything out of it... looks like a frame to me that surrounds the figure

[planetmaker]

I think it's a red cap which it wears. Here without too much changing background:

new_statue2.png (7.92 KiB) Viewed 5777 times

[Alberth]

I don't know much about how to make a nice graphics set, but the statue looks somewhat out of place to me for some reason.

Maybe it is the level of detail compared to the buildings, or the smooth colours (the colours of the building seem harder, maybe there are less colours there?).

The idea of the statue in itself seems nice though.


@everybody: the graphics look really great. I cannot wait until all sprites are done, so I can play toyland with some reasonable background colours

Albert

[edorfaus]

I've noticed that there's lots of buildings in toyland that don't have their construction(unwrapping) stages done, and figured that shouldn't be too hard, since it's really just a box with a pattern (as a start at least). So, naturally, being who I am, I didn't make a wrapper design - but instead a wrapper designer program. (Well, it does have a small default pattern.)

What it does is let you make a pattern (size up to you), and then it repeats that pattern all the way around the box (automatically darkening it for the sides, when it can). It is possible to adjust the pattern for each of the three sides individually, and also to edit the final rendering. The height of the box is fully adjustable.

Best part? It's completely client-side browser-based, only using DHTML, CSS and JS, no flash/java/php/etc. (It's only been tested with FF3 though, other browsers might not work.)

I'm not so sure it's any kind of intuitive though... On the other hand, it's not really meant for end-users (of the game), just us here. If you have any questions, feel free to ask (I haven't mentioned everything about it). A couple of hints: try the "Fill 3D box" button; and click, don't drag.

There are some nice-to-have features that are missing still, such as automatically drawing the middle half-unwrapped stage (it only draws the fully wrapped one at the moment), and saving directly to an image (it can save/load a JSON array format - which I doubt (m)any other programs support - this can be worked around by taking a screenshot though). I intend to add at least some of these things - but, eventually.

Also, fair warning, while the downloaded code is only ~80K, memory usage is probably a lot higher (last time I loaded it, without doing anything, I found 21274 table cells in the document... all added via JS). It's not very fast either, but usable IMO.

Anyway; I've put it up here for now, in case anyone's interested.

I figure I'll probably get around to actually wrapping some buildings eventually, with what I can come up with for a pattern (unless someone beats me to it, hint hint ;) ).

[planetmaker]

I've noticed that there's lots of buildings in toyland that don't have their construction(unwrapping) stages done, and figured that shouldn't be too hard, since it's really just a box with a pattern (as a start at least). So, naturally, being who I am, I didn't make a wrapper design - but instead a wrapper designer program. (Well, it does have a small default pattern.)

Cool stuff!

I've a few problems with it, though: how do I get a sprite loaded into it? I completely fail at it, nothing happens, if I press the "load sprite" button. Further, the chosen pattern seems to be applied not to all sides when chosing "apply to all sides), at least not in the colour scheme I just chose:

[edorfaus]

I probably should have explained this better when I first posted about it...

I've a few problems with it, though: how do I get a sprite loaded into it? I completely fail at it, nothing happens, if I press the "load sprite" button.

Yeah, that's the thing I mentioned about saving to image, the same goes for loading... There is currently no support whatsoever for save/loading to/from files. Nor is there any support for common image file formats. Partly this is due to the entire thing being javascript (not much support for this kind of thing), but I think I might be able to get around some of it with the new HTML5 canvas element that's starting to be supported in modern browsers. I'll have to look into it and implement support for it before it works though.

The load/save that is there, does its work with the text field in between the button rows, and is really mostly for keeping work for continuing later.
It might be easier to understand how this works if you play with the save/load buttons a bit, but basically, save creates a 2D array out of the pixel data in the chosen editor box, serializes it as JSON, and puts the result in the text field. Load expects data on the same format to be present in the text box, and does the reverse, putting it into the editor. (Note however that load uses the same fill method as the buttons, so if you load a small image to a larger editor, it will be tiled.)

Further, the chosen pattern seems to be applied not to all sides when chosing "apply to all sides), at least not in the colour scheme I just chose:

This is because of the feature that makes it automatically use darker shades for the sides than for the top. This is a very simplistic algorithm - it expects that you've chosen colors that, when you take the color with the palette index before it, and the one before that again, it's the same color in darker shades. If that's not the case, you get odd colors like this.

In short, it does the same thing as the "color: --" button (well, link), it decreases the color index on every pixel by one, then uses that for the right-hand side, then decreases again, and uses that for the left-hand side; except it does it without changing the pattern you're working on.

You can avoid this automatic color changing by not using the "fill all sides" and "fill 3d box" buttons, instead using the buttons for each side separately.


I've done some more work on it now (new version in the same place), it's basically the same as before except it now supports drawing the back walls, and supports transparency better (transparent-blue pixels won't be drawn on top of what's already there (note that the "all" buttons clear first)). Using this it is now possible (but not yet convenient) to make the second construction stage as well, except for getting the building's sprite into the middle of things...


PS: A hint for quicker color selection: if you ctrl-click on an image editor, you select the color on the pixel you clicked. :)

[Born Acorn]

They look very nice, I guess, beside the passenger waggons, we would need the mail and goods/valuables in that livery. The rest could be used from existing rail. What do you think?
If you want someone to make a preview newgrf, please post the single sprites.

Greets
Ammler

I've given more thought to this, and after having a game with express Maglev mail, I can see why such things are required.

So attached is a possible design + sprites. The design is taken from the existing monolev mail wagon, I've darkened the CC a tad and made it similar to the passenger carriage.

mailwagons.png (2.67 KiB) Viewed 5098 times

Regarding Signals:

So if you're happy with the original OpenTTD ones (the left hand side ones), you don't have to draw anything

These have been sitting on my website for a while now. If they're acceptable, I can finish missing sprites.

[edorfaus]

New version out now, with a couple more useful features.

how do I get a sprite loaded into it?

This is one of the new features - there's a new "Box content" box, which has a text box named "Sprite" and a "Load" button - enter the number of a sprite (from the ogfx1_base.grf) and hit load, and that sprite will show up in this box, and be used as the "content" of the rendered 3D box.

This fetches sprites from the latest nightly (at the time of writing; updates only happen manually for now, so r144 until I update it).

Note that although the ogfx sprite is shown in an editable box, changing it will not actually be reflected in the 3D rendering.


The other new feature is an automatic box opener, which removes the top and randomly lowers the sides (with some limiters to avoid spikes).

Using these two new features, I made this image, by just entering two numbers and clicking 11 times:

Example house made with my box editor

quick-house.png (1.99 KiB) Viewed 4714 times

(To be exact: enter sprite number 6429, hit load, enter 64 in height box and click to set the height, then clicked fill all sides, clear to dominant rear left and rear right, click a few times on randomly, weighted and very weighted, and then draw all in 3D view. I'm not counting the printscreen and paste+save in PSP.)

Now, I won't be able to easily recreate that image exactly, but as long as "similar" is close enough, it's not a problem. If we find there's a use for exactly, I could replace the PRNG with one that allows us to set the seed (unlike the builtin one), but if it's not needed I don't see the point.


I feel that even in its current state, this tool should make it fairly easy to quickly make packaging for the toyland houses, and also to replace it later if one comes up with a better (or just different) pattern.


I do have one question btw... Can the packaging use the company colors, or otherwise get some colors that change from house to house? If so, that could be a way to get the packaging to not be the same everywhere... No substitute for actually different patterns, but a supplement or stopgap perhaps.

[planetmaker]

They look very nice, I guess, beside the passenger waggons, we would need the mail and goods/valuables in that livery. The rest could be used from existing rail. What do you think?

So attached is a possible design + sprites. The design is taken from the existing monolev mail wagon, I've darkened the CC a tad and made it similar to the passenger carriage.

mailwagons.png

Looks nicer indeed. Hm, I wonder though if mail and goods should feature slightly different sprites? Or shall we use these for both?

Concerning signals: They look nice and distinguishable; maybe a way to go

New version out now, with a couple more useful features.
(...)
I feel that even in its current state, this tool should make it fairly easy to quickly make packaging for the toyland houses, and also to replace it later if one comes up with a better (or just different) pattern.

Cool. Now I'm really looking forward to packaged sprites
Concerning the CC use I don't know right now either

[edorfaus]

Cool. Now I'm really looking forward to packaged sprites :-)

Well, here ya go... I spent a few hours I shouldn't have and came up with these.

gift-wrapped-houses.png (23.95 KiB) Viewed 4340 times

A somewhat boring and repetetive pattern, and monotonous despite the colors (since it's just the same pattern), but better than nothing, right?

I've also encoded them in a .grf (based on r144, link because it's 2.6M), this was done by pasting the image into the existing place for it, and assuming that the offsets are still correct. This assumption should hold if the original sprites had the box centered at the bottom of the sprite, and from a quick look in OTTD this appears to be correct (but I haven't checked closely).

As for in-game automatic recoloring (based on company colors), it appears that this works - but only for some of the houses. The two low houses with antennas on them, have a roof that changes color... but I used company colors on the box for the teapot just to check, and it seems to be staying blue.

[planetmaker]

Nice work! Let's try to get them ingame now

[FooBar]

Very nice! Although it seems monotonous if you see 'em all next to each other, one mustn't forget that there's not that much construction happening at the same time in a certain town. I think it will look good even if all wrappers are the same. The different colours are a great addition!

[Korenn]

I think they need a bow on the top, and perhaps a name-tag.

[mrMann]

I agree with the bow suggestion, but I'm a bit more hesitant towards the name tag.

[edorfaus]

Well, if you can draw a bow that fits (with or without tag, up to you), I can paste it into the sprites...

The boxes were easy, they're just flat surfaces I sent through a custom 3D renderer, but drawing a bow and getting it to look nice is a bit more than I want to try for at the moment...

Edit:
By the way planetmaker, is there anything more I should do to get them ingame?
(I suppose I could provide a grd if you'd rather have that than the modified grf...)

[planetmaker]

Right. A concept for 4625

In the concept sprite, IMO, the windows are comparatively small to the steel part of the facade of the building (assuming that the light blue is the painted steel) which to me makes it look also a bit blurry. But I think it's a good start

[Ammler]

(I suppose I could provide a grd if you'd rather have that than the modified grf...)

Best would be a NewGRF, then we have the pcx and the alignment, all in one.

Greets
Ammler

[planetmaker]

By the way planetmaker, is there anything more I should do to get them ingame?
(I suppose I could provide a grd if you'd rather have that than the modified grf...)

As Ammler says, a grf with only those sprites would be awesome. Then it's a simple matter of copy & paste to include it.
As it stands now, I have to measure the size & offsets of each - which is quite a bit of work to get right

[edorfaus]

Best would be a NewGRF, then we have the pcx and the alignment, all in one. ;-)

OK... Do you have any hints on how to best/easiest make a NewGRF out of the grf/pcx/nfo files I have now?

Should I just copy the relevant sprite lines from the base nfo to a new file and encode (with grfcodec) a grf from that?

Edit:

As it stands now, I have to measure the size & offsets of each

Those are already in the grf I linked, aren't they? Or have I misunderstood something here?