Page 16 of 21
Posted: 26 Oct 2005 10:50
by Brianetta
Purno wrote:Nice, but I still think the space between the coaches should be reduced...
They wouldn't be Lego trains if they had less space between the coaches. That's where the magnetic coupling goes. Lego trains rock.
Posted: 26 Oct 2005 11:43
by Purno
Brianetta wrote:Purno wrote:Nice, but I still think the space between the coaches should be reduced...
They wouldn't be Lego trains if they had less space between the coaches. That's where the magnetic coupling goes. Lego trains rock.
Not really. Look at my newest MU's. That's the same as an pretty old LEGO train (the grey one) had.
Posted: 26 Oct 2005 14:09
by webfreakz.nl
how far is the lego-set done? when could we expected the first working one?
Posted: 26 Oct 2005 14:18
by Mek
webfreakz.nl wrote:how far is the lego-set done? when could we expected the first working one?
not before the first 32bpp ottd is finished?
Posted: 26 Oct 2005 18:55
by Bjarni
Mek wrote:webfreakz.nl wrote:how far is the lego-set done? when could we expected the first working one?
not before the first 32bpp ottd is finished?
before you show up with your next when question, I will say that right now nobody is working on it and while no work is done, the progress indicator says it will be far into the future
some initial coding started once, but it stopped again because the guy working on it left the project. I think I still got the diff if anybody is interested. I will have to say that it's 100% sure that it can't be applied to the current code without some coding and if it is applied, it's not playable anyway
Posted: 27 Oct 2005 16:32
by Mek
Bjarni wrote:Mek wrote:webfreakz.nl wrote:how far is the lego-set done? when could we expected the first working one?
not before the first 32bpp ottd is finished?
some initial coding started once, but it stopped again because the guy working on it left the project. I think I still got the diff if anybody is interested. I will have to say that it's 100% sure that it can't be applied to the current code without some coding and if it is applied, it's not playable anyway
I'm quite sure some initial coding was started at least three (or i believe even four) times.
Posted: 28 Oct 2005 09:07
by bobingabout
i think they were abandoned, since nobody can agree on a format...
Posted: 28 Oct 2005 12:57
by webfreakz.nl
what has to be done when coding a grf?
Posted: 28 Oct 2005 13:02
by bobingabout
this is a 32bpp mod.
can't do 32bpp in grf.
Posted: 28 Oct 2005 13:25
by Alltaken
currently i can provide "standards" that you can meet which will get these GFX to a format the future game will understand.
but no they will not be playable untill that is done.
all that is happening in any 32bpp development is artists are creating all the objects needed so that when the cod is altered the work has already been done and it is playable.
so far i have not seen brickland items rendered in a way that would be able to be put into a game, so currently brickland is in a "model" collecting stage.
then it will need to go to rendering, coding (item info...)
the rendering part could be done now, but the item info coding can't really be done till a format is found.
Alltaken
Posted: 28 Oct 2005 14:08
by DaleStan
webfreakz.nl wrote:what has to be done when coding a grf?
http://wiki.ttdpatch.net/tiki-index.php ... phicsSpecs
(There is/was discussion of 32bbp using grf files (with filenames instead of realsprites[0]), but I digress.)
[0]eg:
Code: Select all
0*0 01 00 01 48
0*0 FC 0F 12 "view000.png" 00
0*0 FC 0C 13 "view001.png" 00
...
instead of
Code: Select all
0*0 01 00 01 48
0 view000.pcx 0 0 01 ...
0 view001.pcx 0 0 01 ...
...
Posted: 29 Oct 2005 10:43
by Bjarni
it's more a question to how the game itself handles the new sprites. Once the graphic engine can actually display them, the question on how to store them, the question of storing them is rather simple in comparison
Posted: 29 Oct 2005 11:25
by Alltaken
Bjarni wrote:it's more a question to how the game itself handles the new sprites. Once the graphic engine can actually display them, the question on how to store them, the question of storing them is rather simple in comparison
the game engine already handles them AFAIK. i have a build here that runs 32bpp sprites. i have asked for it not to be made public untill we decide how to store them. i (personally) don't want lots of GFX being distributed in an incomplete/incorrect format. i also want things like artist credits to be in place before things are distributed.
Alltaken
Posted: 31 Oct 2005 00:59
by DaleStan
Alltaken wrote: i also want things like artist credits to be in place before things are distributed.
How many times must I tell you that there's already
a perfectly good system for storing copyright info, credits, &c.
Posted: 31 Oct 2005 05:40
by Alltaken
yes i know the patch has it (in their GFX GUI) but OTTD doesn't.
it needs to be visable, not somthing you need to read code to see.
Alltaken
Posted: 31 Oct 2005 09:46
by bobingabout
note, most things won't simply have a single sprite image like GRFs do, for what i've been told, each sprite will include 3 images.
the image itself, the shadow mask, and the tri-remap layer for the company colours.
the tri-remap is required because you can't add the remap information to a true colour image the same way to do to a palleted image by reserving colours in that pallete to be remapable, so, the company colours is in a sepereate image. tri-remap allows us to have upto 3 company colours.
Posted: 20 Dec 2005 08:17
by ssmit132
I made a large frieght plane. (Idea from that big six-engined antonov.)
Posted: 20 Dec 2005 08:19
by ssmit132
I made a large frieght plane. (Idea from that big six-engined antonov.)
Posted: 20 Dec 2005 12:26
by dmh_mac
Looks more like a small private jet.
Posted: 20 Dec 2005 12:36
by White Rabbit
You need to give it a better sense of scale. If the plane is so huge, give it MUCH smaller windows. And makes its body wider/fatter (like with Antonovs
).