[OTTD] BRIndustry - Development Thread
Moderator: Graphics Moderators
Re: [OTTD] BRIndustry - Development Thread
Like this?
- Attachments
-
- Gherkin2.jpg (10.73 KiB) Viewed 2068 times
Re: [OTTD] BRIndustry - Development Thread
Yes!
(check out my edit, by the way of my previous post)
And an EDIT to this post
The swirls are the wrong way round now...
(check out my edit, by the way of my previous post)
And an EDIT to this post
The swirls are the wrong way round now...
Projects: http://www.tt-forums.net/viewtopic.php?f=26&t=57266
Screenshots: http://www.tt-forums.net/viewtopic.php?f=47&t=56959
Scenario of The Netherlands: viewtopic.php?f=60&t=87604
Winner of the following screenshot competitions:
sep 2012, jan 2013, apr 2013, aug 2013, mar 2014, mar 2016, oct 2020
All my work is released under GPL-license (either V2 or V3), if not clearly stated otherwise.
Screenshots: http://www.tt-forums.net/viewtopic.php?f=47&t=56959
Scenario of The Netherlands: viewtopic.php?f=60&t=87604
Winner of the following screenshot competitions:
sep 2012, jan 2013, apr 2013, aug 2013, mar 2014, mar 2016, oct 2020
All my work is released under GPL-license (either V2 or V3), if not clearly stated otherwise.
Re: [OTTD] BRIndustry - Development Thread
Back on the topic of industries, im going to drop the sugar beet cargo in favour of nuclear waste.
I wondered if i could roll sugar beet and fruit into a single cargo but not sure what itd be called. Is Fruit and Vegetables too long and oddly specific?
EDIT: Easy solution, the cargo will simply be "Produce". That covers all agricultural products
I wondered if i could roll sugar beet and fruit into a single cargo but not sure what itd be called. Is Fruit and Vegetables too long and oddly specific?
EDIT: Easy solution, the cargo will simply be "Produce". That covers all agricultural products
Re: [OTTD] BRIndustry - Development Thread
I think that 1x1 is just too small for such building.
If you want to have an idea about well scaled skyscrapers then you can check buildings here: http://www.simuscape.net/simutalk/viewt ... f=29&t=426
And I like the darker one more. Looks less like a mushroom and has nicer colors in my opinon.
If you want to have an idea about well scaled skyscrapers then you can check buildings here: http://www.simuscape.net/simutalk/viewt ... f=29&t=426
And I like the darker one more. Looks less like a mushroom and has nicer colors in my opinon.
Re: [OTTD] BRIndustry - Development Thread
If you combined the left shard with the right, it would fit, purely blue looks to cartoony to fit in, and the dark one would only look good in Night GFX.
Re: [OTTD] BRIndustry - Development Thread
I agree with this sentiment, thing is everyone has a different view on how tall buildings should be. but a building like the gherkin certainly deserves atleast a 2x2 tile.luxtram wrote:I think that 1x1 is just too small for such building.
but then yes i'm a proponent of larger buildings in openttd as you will have noticed from the size I've been drawing my objects.
All my projects are GPLv2 License.
Dutch landmark Object Set Workshop viewtopic.php?f=26&t=75071
My stations workshop viewtopic.php?f=26&t=74749
Dutch landmark Object Set Workshop viewtopic.php?f=26&t=75071
My stations workshop viewtopic.php?f=26&t=74749
Re: [OTTD] BRIndustry - Development Thread
Well considering the shard is going to be in the set and is substantially taller than the gherkin, i cant really justify making the gherkin any bigger
- andythenorth
- Tycoon
- Posts: 5658
- Joined: 31 Mar 2007 14:23
- Location: Lost in Music
Re: [OTTD] BRIndustry - Development Thread
Use 2x2, but don't cover the whole footprint, e.g. use 1.5 tiles for the building, the rest is pavement.
FIRS Industry Replacement Set (released) | HEQS Heavy Equipment Set (trucks, industrial trams and more) (finished)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Unsinkable Sam (ships) (preview released) | CHIPS Has Improved Players' Stations (finished)
Iron Horse ((trains) (released) | Termite (tracks for Iron Horse) (released) | Busy Bee (game script) (released)
Road Hog (road vehicles and trams) (released)
Re: [OTTD] BRIndustry - Development Thread
I am afraid that you can not fit everything into game and get away with everything looking good.Leanden wrote:Well considering the shard is going to be in the set and is substantially taller than the gherkin, i cant really justify making the gherkin any bigger
For example some people tried with Tokyo Sky City 1000 and it looks, well, not good at all.
Similar example is the Empire State building. To fit it into game you have to scale it very small and in the end it will still not look good enough.
If you scale everything based on it then everything will look bad.
Of course you can do as you want. My hope is that if you are going to draw something then it would be also useful outside your personal scenario.
This applies of course when you follow the 256 pixel height limit.
Why is there such limit at all and what would happen when one fits one object higher than that into game?
Re: [OTTD] BRIndustry - Development Thread
you get clipping issues, I don't know if you use TTRS, but there is a skyscraper in that set which is taller than the 256 limit and it clips once and a while.luxtram wrote:what would happen when one fits one object higher than that into game?
I don't mind clipping if its not to bad, and I have drawn buildings taller than the limit. but try not to if not needed.
All my projects are GPLv2 License.
Dutch landmark Object Set Workshop viewtopic.php?f=26&t=75071
My stations workshop viewtopic.php?f=26&t=74749
Dutch landmark Object Set Workshop viewtopic.php?f=26&t=75071
My stations workshop viewtopic.php?f=26&t=74749
Re: [OTTD] BRIndustry - Development Thread
Well ive based it on the shard being 255 pixels tall, but in all honesty its down to whatever is drawn
I will try and draw but im a very poor pixel artist so its pretty much relying on contributions of others
I will try and draw but im a very poor pixel artist so its pretty much relying on contributions of others
Re: [OTTD] BRIndustry - Development Thread
Yes, I have seen them. These do not look that bad. What annoyed me more were some clipping with park overlay tiles for the "underground" station.Silverx50 wrote:you get clipping issues, I don't know if you use TTRS, but there is a skyscraper in that set which is taller than the 256 limit and it clips once and a while.luxtram wrote:what would happen when one fits one object higher than that into game?
I don't mind clipping if its not to bad, and I have drawn buildings taller than the limit. but try not to if not needed.
Then why not draw it a little higher and offer it as an object?
Also, does anyone know the actual reason behind this clipping?
Re: [OTTD] BRIndustry - Development Thread
Yes, the game uses the hexadecimal numeral system https://simple.wikipedia.org/wiki/Hexad ... ral_system. Which is a handy system to convert numbers with 3 digits (so 100 and up) to 2 digits. Its a coding thingyAlso, does anyone know the actual reason behind this clipping?
255 (normal numeral) = FF (hexadecimal). FF is the maximum number the game can "understand" for hights, its the maximum number possible for boundingboxes. Buildings taller than that will "confuse" the sprite-sorter so glitching will appear occasionally at the parts higher than 255 pixels.
At least this is how I understand it
So, taller buildings are possible, but will have graphical issues sometimes....
Projects: http://www.tt-forums.net/viewtopic.php?f=26&t=57266
Screenshots: http://www.tt-forums.net/viewtopic.php?f=47&t=56959
Scenario of The Netherlands: viewtopic.php?f=60&t=87604
Winner of the following screenshot competitions:
sep 2012, jan 2013, apr 2013, aug 2013, mar 2014, mar 2016, oct 2020
All my work is released under GPL-license (either V2 or V3), if not clearly stated otherwise.
Screenshots: http://www.tt-forums.net/viewtopic.php?f=47&t=56959
Scenario of The Netherlands: viewtopic.php?f=60&t=87604
Winner of the following screenshot competitions:
sep 2012, jan 2013, apr 2013, aug 2013, mar 2014, mar 2016, oct 2020
All my work is released under GPL-license (either V2 or V3), if not clearly stated otherwise.
Re: [OTTD] BRIndustry - Development Thread
Actually, it's due to the binary nature of computer systems.
Each bit can 0 or 1, so if you have N of these, you can represent 2^N different values. Relevant values here are 2^3=8, 2^6=64, 2^7=128, 2^8=256, and 2^16=65536.
At the time, people wanted to store text into a computer, ASCII was designed. Since it's an Amercian standard, only the letters used in the English language needed a place. It's quite easy to see you'd want lower case letters, upper case letter, and digits at least. That are 26+26+10 = 62 characters. Then you'd want space, carriage-return, line-feed (think mechanical type writers here!), and some dashes, slashes, etc.
In any case, more than 64 characters, so 6 bits won't work. You need at least 7, giving you 128 characters. You can look at how it got filled by looking at an ASCII table.
All was fine again, until you needed to access the bits themselves in a memory, or in a CPU. 7 is not a 2^N number, making things awkward. Luckily, 2^3 is 8, so we got 1 bit extra with each character. This one extra bit gave 128 more characters, which was used for the high-ascii plane later in time, with additional letters in it.
This made multiples of 8 bit special. The entire design of processors and memory evolved around this, and we ended up with 1 byte = 8 bit as being the unit of storage in a cell of memory. Coders think in this unit. So when CS had to decide how to store the height of a building, his choices were 1 byte, 2 byte, or 4 byte (3 byte is again not a 2^N number, and skipped). Since he expected around 50-100 pixels (non-zoom!) height, 1 byte was sufficient, as that gives 2^N is 256 different values, from 0 to (and including) 255. Note that memory was horribly expensive in those days, 2 bytes would have doubled the storage requirements for no good reason, due to his expected max height.
So that's how the 255 limit was created.
The hexadecimal number system became standard for writing bit patterns, since long 0/1 sequences is too complicated in practice. The hexadecimal system uses base 16 as you can expect from its name. One hexadecimal digit can thus express exactly 4 bits (2^4==16), 2 digits express exactly 8 bits, or 1 byte.
It takes a little practice, but reading 0/1 patterns from a hexadecimal number is easy, much easier than with values in the decimal system (10 is not a 2^N number).
Each bit can 0 or 1, so if you have N of these, you can represent 2^N different values. Relevant values here are 2^3=8, 2^6=64, 2^7=128, 2^8=256, and 2^16=65536.
At the time, people wanted to store text into a computer, ASCII was designed. Since it's an Amercian standard, only the letters used in the English language needed a place. It's quite easy to see you'd want lower case letters, upper case letter, and digits at least. That are 26+26+10 = 62 characters. Then you'd want space, carriage-return, line-feed (think mechanical type writers here!), and some dashes, slashes, etc.
In any case, more than 64 characters, so 6 bits won't work. You need at least 7, giving you 128 characters. You can look at how it got filled by looking at an ASCII table.
All was fine again, until you needed to access the bits themselves in a memory, or in a CPU. 7 is not a 2^N number, making things awkward. Luckily, 2^3 is 8, so we got 1 bit extra with each character. This one extra bit gave 128 more characters, which was used for the high-ascii plane later in time, with additional letters in it.
This made multiples of 8 bit special. The entire design of processors and memory evolved around this, and we ended up with 1 byte = 8 bit as being the unit of storage in a cell of memory. Coders think in this unit. So when CS had to decide how to store the height of a building, his choices were 1 byte, 2 byte, or 4 byte (3 byte is again not a 2^N number, and skipped). Since he expected around 50-100 pixels (non-zoom!) height, 1 byte was sufficient, as that gives 2^N is 256 different values, from 0 to (and including) 255. Note that memory was horribly expensive in those days, 2 bytes would have doubled the storage requirements for no good reason, due to his expected max height.
So that's how the 255 limit was created.
The hexadecimal number system became standard for writing bit patterns, since long 0/1 sequences is too complicated in practice. The hexadecimal system uses base 16 as you can expect from its name. One hexadecimal digit can thus express exactly 4 bits (2^4==16), 2 digits express exactly 8 bits, or 1 byte.
It takes a little practice, but reading 0/1 patterns from a hexadecimal number is easy, much easier than with values in the decimal system (10 is not a 2^N number).
Being a retired OpenTTD developer does not mean I know what I am doing.
Re: [OTTD] BRIndustry - Development Thread
Well that is a brilliant summary thanks Alberth
So to summarise i could make the Shard more than 255 pixels even though itll glitch, but then all other buildings will still be within scale
So to summarise i could make the Shard more than 255 pixels even though itll glitch, but then all other buildings will still be within scale
Re: [OTTD] BRIndustry - Development Thread
lol, Alberths excellent summary shows that I am not a computer programmer
Yes, because the graphics blocks of the code work with "normal" numbers and are not limited to 255.So to summarise i could make the Shard more than 255 pixels even though itll glitch, but then all other buildings will still be within scale
Projects: http://www.tt-forums.net/viewtopic.php?f=26&t=57266
Screenshots: http://www.tt-forums.net/viewtopic.php?f=47&t=56959
Scenario of The Netherlands: viewtopic.php?f=60&t=87604
Winner of the following screenshot competitions:
sep 2012, jan 2013, apr 2013, aug 2013, mar 2014, mar 2016, oct 2020
All my work is released under GPL-license (either V2 or V3), if not clearly stated otherwise.
Screenshots: http://www.tt-forums.net/viewtopic.php?f=47&t=56959
Scenario of The Netherlands: viewtopic.php?f=60&t=87604
Winner of the following screenshot competitions:
sep 2012, jan 2013, apr 2013, aug 2013, mar 2014, mar 2016, oct 2020
All my work is released under GPL-license (either V2 or V3), if not clearly stated otherwise.
Re: [OTTD] BRIndustry - Development Thread
Euhm, yeah, you canLeanden wrote:So to summarise i could make the Shard more than 255 pixels even though itll glitch, but then all other buildings will still be within scale
I am not sure it's a good idea though, I consider glitching buildings to be very much broken.
Scale in openttd doesn't exist other than "it works for the game", as far as I know. In particular, it has little relation with reality. Since you typically don't put these buildings right next to each other, differences in scale are not as apparent in a game. If you blend it with any other object set, you're practically doomed anyway. I would try to make each building looks as good as possible on its own compared with buildings that you typically add around it. Even sacrificing a few floors if that makes the overall look better is a choice you can make.
To summarise, don't ask me what a good choice is
I would go for "inspired by reality" rather than "reproduced from reality", but you're the artist, so you have the final decision
Being a retired OpenTTD developer does not mean I know what I am doing.
Re: [OTTD] BRIndustry - Development Thread
Yes, indeed.Leanden wrote:Well that is a brilliant summary thanks Alberth
So to summarise i could make the Shard more than 255 pixels even though itll glitch, but then all other buildings will still be within scale
And make it available as an object. Then people who would like to use it and do not mind the glitching, can use it.
And people who would like to use it but hate the glitching, can pressurise the devs to solve the glitching issue (i.e. use more that 1 byte for the building sprite height).
I think that this would be much more reasonable way than following the 2 decades old unfortunate software design decision.
Edit: a small clarification (as per Leanden kind suggestion): this must read as: this is my personal view how it would make the most sense to do it, you of course could do how ever you please.
So perhaps my English senses failed (not my first language, sorry), but how I meant it was:
"So to summarise i could make the Shard more than 255 pixels even though itll glitch, but then all other buildings will still be within scale"
and I suggest to make it available as an object as this is likely the most optimal common ground and helps to direct the game in a good direction (well, in my opinion at least, every one else mileage may wary).
As an additional note: there are many buildings that would heavily benefit from this, I would say, change of attitude. That is that it is not the artist problem that a building glitches but it is a problem in the game code that should be addressed.
Last edited by luxtram on 11 Jun 2016 22:51, edited 2 times in total.
Re: [OTTD] BRIndustry - Development Thread
I appreciate your comments luxtram but i would just say reading your comments in both mine and silvers posts you should perhaps frame your suggestions in a different way as it very much comes across that you are telling us how we should design our sets and that if we dont agree with you we are wrong.
Just my two cents, dont stop giving feedback but just try to approach it differently or people will get annoyed.
Just my two cents, dont stop giving feedback but just try to approach it differently or people will get annoyed.
Re: [OTTD] BRIndustry - Development Thread
Thanks! I am really thankful that you pointed this out and perhaps this is something I could work on with my personal English trainer as I especially have tried to word it like the opposite of how you sense it.Leanden wrote:I appreciate your comments luxtram but i would just say reading your comments in both mine and silvers posts you should perhaps frame your suggestions in a different way as it very much comes across that you are telling us how we should design our sets and that if we dont agree with you we are wrong.
Just my two cents, dont stop giving feedback but just try to approach it differently or people will get annoyed.
But in general how you probably have to look at my posts is that have the pixels on my screen that I like to look a certain way, but I do not have the time to paint all of them by myself, so the next best thing I could do is to convince others to not deviate too much from my own vision.
So my actual opponent of the discussion is not you.
It is the person who tries to convince you that you could draw how ever you please. And they are totally right, but, and here comes my part, I think that drawing it by following certain general guidelines makes more sense than others. Both in the artistic sense but also in the sense of the game development in the longer perspective.
One of such general guidelines is in my opinion the integrity of the heights of the same class objects.
That is for example that if you draw a locomotive, you do not draw it one third or twice as small as the other similar size engines. Of course you could, but I would find it really odd, sorry , and I would very likely not use your engine in my game (of course you could still draw it like that and I will not be mad at you, just a little sad that I could not use your wonderful work).
I think that the same applies also to the buildings more or less.
And I hope to convince you that it actually makes sense.
Who is online
Users browsing this forum: No registered users and 76 guests