bigsig (schematic signal set) [final design]

Discuss, get help with, or post new graphics for TTDPatch and OpenTTD, using the NewGRF system, here. Graphics for plain TTD also acceptable here.

Moderator: Graphics Moderators

Post Reply
User avatar
changnian
Engineer
Engineer
Posts: 26
Joined: 12 Oct 2010 08:23

bigsig (schematic signal set) [final design]

Post by changnian »

This thead is dedicated to the development of bigsig. The intent is to provide a set of signal graphics that are more easily seen and interpreted but do not have a realistic appearance. No new functionality is contemplated, just a set of signal sprites.

Considerations:
  • Signals should be large enough to be seen clearly even on high-resolution screens.
  • Signals should not be so large as to completely dominate or overshadow other game elements.
  • All properties of every signal must be visible: type, direction, state.
  • Signals that 'face' away from the player should be no less visible or clear.
  • Display of properties should demand little or no explanation.
  • Might be nice if original light signals were always shown and bigsigs could be shown/hidden with a hotkey toggle.
I will be designing and producing actual graphics work. As always, suggestions and collaborators are welcome.
Last edited by changnian on 14 Nov 2010 11:43, edited 2 times in total.
-Xiong
User avatar
changnian
Engineer
Engineer
Posts: 26
Joined: 12 Oct 2010 08:23

Re: bigsig -- Larger, more visible, schematic signal set

Post by changnian »

Here's a very rough demo:
Demo; do not use.
Demo; do not use.
bigsig-002.png (28.64 KiB) Viewed 7386 times
The round dot is a block signal, the diamond a two-way path signal, and the bar -- well, I dunno: entry pre-signal, exit, or combo. The one-way path would be half of the diamond pointing in the direction of permitted travel.
-Xiong
User avatar
CommanderZ
Tycoon
Tycoon
Posts: 1872
Joined: 07 Apr 2008 18:29
Location: Czech Republic
Contact:

Re: bigsig -- Larger, more visible, schematic signal set

Post by CommanderZ »

Idea for symbols:
Filled symbol - block signal
Outline symbol - path signal
Circle - bidirectional
Arrow - single-directional

Presignals could have some sort of additional symbol inside.
User avatar
changnian
Engineer
Engineer
Posts: 26
Joined: 12 Oct 2010 08:23

Re: bigsig -- Larger, more visible, schematic signal set

Post by changnian »

There seems to be some confusion regarding terms. It is quite inconvenient to post a screenshot every time one wants to refer to something; it's quicker and easier to use words. But then, of course, these words must be agreed upon.

The following terms have been chosen, after two hours' discussion on IRC, to discuss the items pictured. --In this thread, at least.
Plain Track Terms
Plain Track Terms
plain-track-terms.png (126.77 KiB) Viewed 7201 times
Terms shown are case-insignificant. Terms shown in red are taken directly from http://vcs.openttd.org/svn/browser/trun ... ack_type.h. Terms shown in blue are directions and refer not to track itself but to motion or displacement along it. Terms shown in orange define classes of track. Thus, the GA class includes X and Y track; the NGA class includes UPPER, LOWER, LEFT, and RIGHT track.

Note the scope of this figure is limited to plain track: track without intersections, turnouts, crossovers, tunnel entrances, station platforms, or any other thing. Signals cannot be placed on such track; therefore it does not enter into this thread.
-Xiong
User avatar
belugas
OpenTTD Developer
OpenTTD Developer
Posts: 1507
Joined: 05 Apr 2005 01:48
Location: Deep down the deepest blue
Contact:

Re: bigsig -- Larger, more visible, schematic signal set

Post by belugas »

Terms are good regarding the picture displayed
If you are not ready to work a bit for your ideas, it means they don't count much for you.
OpenTTD and Realism? Well... Here are a few thoughs on the matter.
He he he he
------------------------------------------------------------
Music from the Bloody Time Zones
User avatar
Zephyris
Tycoon
Tycoon
Posts: 2890
Joined: 16 May 2007 16:59

Re: bigsig -- Larger, more visible, schematic signal set

Post by Zephyris »

I think this is an excellent idea and I look forward to seeing the finished product!
User avatar
jvassie
Tycoon
Tycoon
Posts: 3421
Joined: 18 Dec 2002 18:00
Location: High Wycombe, England
Contact:

Re: bigsig -- Larger, more visible, schematic signal set

Post by jvassie »

I fully endorse this product and/or service. [/Meme]

This looks like a very interesting way of using signals. Begs for the idea of switching between this and standard signals, for screenshot purposes etc :D
(British) Modular Stations Set - Thread: | Website:
Swiss Set - Thread: | Website:
Route Map Creator
My Screenshot Thread
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: bigsig -- Larger, more visible, schematic signal set

Post by planetmaker »

jvassie wrote:This looks like a very interesting way of using signals. Begs for the idea of switching between this and standard signals, for screenshot purposes etc :D
Actually... It might indeed be a nice idea to incorporate such alternative signals via the transparency switches. Like transparent signals = flat, big signals as proposed here. It could indeed also help to make certain track arangements clearer AND would offer a way to supply a uniform way of signals, given the variety of newgrf around.
User avatar
Zephyris
Tycoon
Tycoon
Posts: 2890
Joined: 16 May 2007 16:59

Re: bigsig -- Larger, more visible, schematic signal set

Post by Zephyris »

Yeah, there is a lot of potential for this both as a standalone graphics set and as a built-in transparency/visibility option...
User avatar
changnian
Engineer
Engineer
Posts: 26
Joined: 12 Oct 2010 08:23

Re: bigsig -- Larger, more visible, schematic signal set

Post by changnian »

Here, by popular demand, is the first bigsig concept, which I still think is not right at all:
bigsig-001.png
bigsig-001.png (9.74 KiB) Viewed 6800 times
I'm not convinced that 002 is not just as bad as 001; it may be worse. The serious objection to 002 is track built on slopes. A minor objection is that since a tile can share up to 4 signals, they cannot all rationally compete for center-of-tile. That's more of a detail than a deal-killer.

After some experimentation (not much), it is clear that GA track can be built in continuous runs both up/down GA slope and across it. It can even be built slanting down the face of NGA slope. However, close examination of the results suggests that all of these are forms of the up/down run and flat track: track built across GA slopes is leveled to flat track and track slanting across NGA slopes is the same as up/down track. The keyword here is embankments.

Moving to NGA track, it seems that it cannot be built at all on slopes of either type -- not in continuous runs. However, it is possible to build some individual bits. I have not yet been able to incorporate any of this NGA-on-slope track into any sort of mixed run but I allow the possibility. Still, I find it unlikely that such a NGA track bit could be built in such a way as to permit it to be signalled.

This leaves only the two main cases of GA track runs: sloped and flat; and the single case of NGA flat.

Each of GA|NGA track comes in 2 orientations (4 orientations total: X, Y, U/L, L/R); and for each orientation there are 2 directions of travel, yielding the unsurprising product 8 (N, NE, E, SE, S, SW, W, NW). When first I proposed bigsig, I imagined that 8 sprites of each of 6 types of signal (block, entry, exit, combo, path, 1path) in each of 2 aspects (red/green) = 96 sprites total would be required; this calculation has been confirmed by several people on IRC (although I would dearly love to see someone say it on the record, here in this thread). But this assumes that signals are drawn the same for GA sloped as for GA flat.

I don't want to argue with this but it explodes the idea of signals that lay flat on the track itself. No matter how cleverly drawn, signals that lay flat and directly 'above' flat track will render as sticking out from some sloped track and buried in the hillside on others. Perhaps some clever dodges can make them visible in all orientations of slope but they will look ugly and bad; certainly they will not appear to follow the slope of the track. To do so would require that OTTD accept a total of 192 signal sprites. (?) Someone with authoritative knowledge will have to say if this is practical, from a game mechanical viewpoint. I suspect it is not; and that the idea is exploded.
... transparency...
I agree strongly that bigsig should tie into transparency in some way. Outsize signals will look bad on the surface, however good they are in terms of underlying form. I would suggest, though, that bigsig should be the transparent form, with whatever other signal set a user has chosen being the normal, opaque form. It is clear that the game provides transparent forms for each normally opaque object; I think I'm right to say these are not generated dynamically from the opaque forms but drawn and loaded separately. So, bigsig should be considered only the transparent form of a signal. This may be complicated by the fact that there does not seem to be a transparent setting for roads, tracks, or signals.

Summary:
  • Both 001 and 002 suck. This is fine. I'd be dismayed if my final work was like my first sketch. Final work needs to be better.
  • If adding another 96 sprites to the signal system is the easier fix, then my work will develop from 002.
  • If adding signal transparency -- preferably in the peculiar form of two active signal sets, in which bigsig is considered the transparent set -- is the easier fix, then my work will develop from 001.
  • If both fixes are easy, then I think it will be good to build on 002.
  • In either case, the design consideration must be added that signals not overlap, even when crowded.
  • If transparency is used, then the consideration of not making bigsigs too big (from a romantic viewpoint) may be relaxed. This also subsumes the 'Might be nice... toggle...' consideration.
  • Transparent bigsigs should not preclude the use of any other signal set as the 'opaque' set.
  • I place a high value on the transparency fix.
By 'easy' and 'easier', above, I mean to say that some competent person is willing to do it. The graphic design depends heavily on both current game mechanics and new mechanics (to be implemented). I'm ignorant of game mechanics and do not expect to do anything past botching the job if I fool with them. Therefore, I can only proceed on this if someone with mechanics experience is willing to commit to that end, part of which will include answering the occasional stupid question. I will be watching this thread for that commitment. :D

I shall note, briefly, something which perhaps must be said, although I'm extremely reluctant to do so. I'm an experienced graphic artist and have a considerable microelectronic engineering background, primarily in digital hardware but with a lot of extension; and I have delivered many complex projects. Currently I'm developing in Perl; you can see some of my work -- not advanced but there -- on CPAN. My major project is a graphics-intensive website that involves ImageMagick and, if I do it right, will look much less clever than it is. If I'm able to lay the proper foundation for bigsig, I commit absolutely to delivering a full set of graphics meeting all technical specs.

<edit> This is twice that I counted 5 signal types. I don't know why. Fixed.
-Xiong
User avatar
changnian
Engineer
Engineer
Posts: 26
Joined: 12 Oct 2010 08:23

Re: bigsig (schematic signal set) [early design]

Post by changnian »

Okay, I thought I'd just about run out of choices; then I got a new idea. This, bigsig-003, is based on the fact that the only thing you really need to see about a signal is what colors it is showing and which way it is facing. Therefore, nothing should be shown except the lights themselves.
Left-hand running!
Left-hand running!
bigsig-003-left.png (17.17 KiB) Viewed 6731 times
Let me point out first of all that I'm an American, accustomed to right-hand running (although we do have some left-hand roads here); and in OpenTTD, I have my signals set on the running, right side of the track. Due to a single careless choice I made very early on in the drawing of this sketch, it has come out LEFT-HAND RUNNING, with signals on the left side of the track from the engineer's viewpoint.

I'll describe the elements of the sketch and then discuss rationale and implications. Please realize this is only a rough sketch; especially, the abundance of signals is not only useless, it's impossible to achieve ingame.

The Sketch

Near the center is a row of five lights not associated with any track. This is the basic set: white, yellow, blue, green, red (W/Y/B/G/R). Each has a 4x4 bounding box and consists of a 2x2 in one shade bordered by another shade of the same color, with the corners clipped off. Transparency is all or nothing and the lights are composed from the ttd-noaction-nocomp.gpl palette.

I have not drawn anything at all except the lights themselves; I put them on existing signal poles, for speed and laziness. Something Bad happened between the screenshot and the finished sketch; the background is strangely dithered.

In the SW corner are 4 sections of NGA track. These are all normal block signals, crammed in as tightly as I could get them ingame.
The western, northbound section has a line of signals on 'proceed', as does the eastern, southbound section (again, left-hand running). The 'inside', facing-wrong-way signals mostly show 'stop' but I've mixed it up a little to better show the effects of overlap. The two E-W sections are both signaled 'proceed' for westbound traffic and 'stop' otherwise.

To the SE is a gallery of all signal types in both aspects, shown on a section of X track. Moving along this section to the NE I show normal, entry, exit, combo, path, and 1-path. All the signals facing a NE-bound train are at 'stop'; all facing a SW-bounder, 'proceed'.

The hill is covered only with 1-path signals showing 'stop'. Yes, this is operationally ludicrous.

Scale

Potentially, signals may be set very close to one another. The idea here is that by eliminating nonessentials, it's possible to make each light bigger without making a much larger signal overall. A tile is 32 px from E to W and on that stretch there can be 2 signals, so I allow 16 px per signal. Three lights at 4px each total 12px, leaving 4 px to distinguish where one signal ends and another begins.

Indication Table

Read from the signal post "out".

1 2 3
-----
W G G : normal block; proceed
W R R : normal block; stop

Y Y G : entry; proceed
Y Y R : entry; stop
W W G : exit; proceed
W W R : exit; stop
W Y G : combo; proceed
W Y R : combo; stop

B Y G : normal path; proceed
B Y R : normal path; stop
B R G : one-way path; proceed
B R R : one-way path; stop

I'm not quite settled on this scheme. Prototypes have tried many different schemes over the years, even ignoring semaphores. Also, OTTD signals are not quite replicas of any prototype, where a common indication is 'proceed with caution'. I certainly don't know of any road that orders engineers to swap end-for-end when they see the back side of a signal. While I believe in realism, bigsig is intended to make game play more straightforward. I'll be interested in suggestions.

Colors

It's difficult to choose from a limited palette to contrast with everything else on the board. The Y and R may be a bit too close together in shade, as will as the B and G. I'll experiment.

Rationale

You do not need to see the signal post to read this (although it may make it easier to figure out on which which track the signal is). The light nearest the engineer (as he would see it) is always R or G. (I leave it as an exercise to figure out how he sees the others, "behind" it from his viewpoint.) The light at the post is always W, Y, or B. Only path signals contain B lights at all. All signals that contain two of W and Y are presignals of some kind.

The entire signal is visible to the player no matter where it is (given that obstructions can be made transparent). For me, at any rate, being able to see which signals are indicating 'proceed' is invaluable in troubleshooting. As it is, even with IMO-better-than-default signals, I can't even tell the type when it's edge-on.

The direction the signal faces is clear, even if the post cannot be seen. Again, the old hands may never think of this but when I'm laying signals in the middle of a busy yard, with steam all over the place and trains smashing into horse carriages, I can hardly tell if I've laid two block signals or one, let alone where the one might have gone.

Realism is great but it stops being fun when you have to crane your neck and squint. When you have to whip out a magnifying glass, I say it's time to create more lucid graphics.

Sloped Track

In my last post, I argued that slopes made novel signal creation very difficult. You see here the same arrangement on the four slopes that you see on the flat. I think it's not great; the signals look a little funny. But they do not actually nose right into the hillside.

Being cheap, for this sketch I just stole existing poles from the screenshot and, therefore, put the new signals over the old signalheads. Of course, I will draw new poles when "for real". I think signals will look better on the flat if the poles are a bit shorter; but they may look worse on slopes. Some thoughts here may help me.

Next

I need a collaborator on this. As I mentioned last post, I know next to nothing about OTTD and it will be as much as I can do to draw the graphics correctly. If you like what you see and want to see more, step up. :bow:
-Xiong
dihedral
Tycoon
Tycoon
Posts: 1053
Joined: 14 Feb 2007 17:48

Re: bigsig -- Larger, more visible, schematic signal set

Post by dihedral »

bigsig-001.png
This was so far my favorite. a bit too big, but i like the image. perhaps if the yellow light and the arrow were combined (e.g. yellow arrow) it could already decrease size a big.
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: bigsig -- Larger, more visible, schematic signal set

Post by planetmaker »

dihedral wrote:
bigsig-001.png
This was so far my favorite. a bit too big, but i like the image. perhaps if the yellow light and the arrow were combined (e.g. yellow arrow) it could already decrease size a big.
Yes somewhat like that. Possibly 2/3 the size, oriented on the driving side of the track, the rectangle already aligned with the track. Not two lights but one which changes from red to green. And the yellow bar as shown below the lights could keep the meaning as the (possible) bars with existing signals: horizontal or vertical colour bar as with existing signals indicating the signal type. For the sake of differenciation the path signals maybe could use double lights as they already do.
User avatar
changnian
Engineer
Engineer
Posts: 26
Joined: 12 Oct 2010 08:23

Re: bigsig (schematic signal set) [early design]

Post by changnian »

I've been asked the purpose of bigsig.
A line of standard signals
A line of standard signals
what-sigs.png (3.75 KiB) Viewed 6556 times
Part of the answer is: Can you tell me the type and indication of these signals? I cannot.
-Xiong
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: bigsig (schematic signal set) [early design]

Post by planetmaker »

The signals you show are not and have never been standard signals. You should start from the right pre-conditions and fix your standard settings.

This is how my standard signals look like when you install OpenTTD out of the box.
Attachments
Neu Fürstenmünster Transport, 12-02-1950.png
Neu Fürstenmünster Transport, 12-02-1950.png (48.57 KiB) Viewed 6552 times
all signal types
all signal types
Neu Fürstenmünster Transport, 03-07-1950.png (41.87 KiB) Viewed 6545 times
User avatar
changnian
Engineer
Engineer
Posts: 26
Joined: 12 Oct 2010 08:23

Re: bigsig -- Larger, more visible, schematic signal set

Post by changnian »

Some comments, some replies
dihedral wrote:(bigsig-001.png) was so far my favorite....
bigsig-001 was my very first attempt at explaining intent. It never was a workable idea and it is totally exploded by crowded signals. There simply are not enough pixels available between two signals on an E-W track that share the same tile. There are 16 pixels, horizontally, into which the sprite must be crammed; and if it is not to merge with its neighbor, some margin must be left. That's how I settled on a 12x12 maximum bounding box (not including post).
planetmaker wrote:And the yellow bar as shown below the lights could keep the meaning as the (possible) bars with existing signals...
Imitating existing signals is the least of my worries. I'm motivated to do this because I can't interpret existing signals; I can't interpret them because they do not make good use of visual cues. A horizontal yellow bar looks just about the same as a vertical yellow bar when both are only a couple of pixels long.

If you want to experience the game as I see it, stand about five feet (a meter or two) away from your monitor. Then tell me where your signals are, much less what they are.
planetmaker wrote:The signals you show are not and have never been standard signals. You should start from the right pre-conditions and fix your standard settings...
Why? I find the signals I'm currently using slightly easier to see. The difference is extremely marginal. This project is intended to do better.

You seem to miss the point of the demonstration. You're unfamiliar with the signal set I used and you find it poorly designed and hard to read. I'm unfamiliar with both sets and I find them both hard to read. I think they both look nice but frankly, I care more what they say.
-Xiong
User avatar
changnian
Engineer
Engineer
Posts: 26
Joined: 12 Oct 2010 08:23

Re: bigsig (schematic signal set) [early design]

Post by changnian »

Major Points

(1) I'm not trying to design a realistic signal set. I would prefer it not look ugly. But my concern is almost entirely with underlying function. Appearance is only important here if it exposes underlying function to the eye. I would rather have a great big ugly box hovering over each signal than lack the information it contained.

(2) I'm not looking to modify, extend, or improve upon the default signal set. They look nice but, from a functional viewpoint, are almost worse than no sprites at all. I would consider it an improvement if all 96 sprites looked exactly alike, so that at least they would not pretend to inform the player.

(3) There is a vast difference between learning a game and playing a game as an expert. There are also wide differences between one person and the next. I understand why some players might consider default signals sufficient. I think all readers of this thread should understand that there might be reasons why others cannot.

Project Goals

Every signal must display at all times, clearly and obviously, these aspects:
  • Track
  • Facing
  • Type
  • Indication
By 'clearly', I mean to say it must be evident to people whose vision is less than perfect. Before making any judgement about clarity, try opening a graphic -- any graphic -- in some viewer and reducing it to 50% or 25% of original, dot-for-dot size. Or step away from your monitor.

By 'obviously', I mean that a novice player must be able to understand what he sees, without elaborate chains of deduction. I admit that after several hours of play, I'm starting to have an easier time with signals; the situation is merely highly annoying, not enraging. Is there a good reason to annoy novices? I think not.

By 'at all times', I mean that if you can see the signal, you should be able to tell what it shows. Transparency settings allow player to remove most obstructions to clear sight. But a signal should be equally visible whether player sees it from its front, back, side, or other angle. Particularly, signals must not obscure one another.

I'm not going to let go of any of these goals; they are all important. Quite honestly, it infuriates me to hear anyone say that any of these are not. Some players may think some of these goals are not important but then, I don't require anyone to get involved. Involvement with bigsig presumes understanding of and respect for these goals.

This isn't meant to be rude or dismissive. But it's not really possible to contribute well to something you think is wrong. If you attempt to do so, then you cause chaos. It would be better to oppose it openly, if you think it is a threat or carries some potential for harm. I don't see how bigsig is capable of this.

You are not required to build, discuss, or use a wheelchair ramp. But I suggest you not scorn those trying to design and build one.

Track

Each signal must show which track it controls. Although track junctions may themselves not be signaled, signals can be placed quite near a junction; also, two parallel NGA tracks can share a tile. Track "curves" (corners) complicate matters. Further, even along a single, straight track, it must be possible to tell exactly where a block begins and ends.

Facing

Every signal has a totally different meaning to a train approaching it from the front or from the back. There can be no question about facing.

I do not consider it sufficient to rely entirely on the placement of a signal to the left or right of a track to indicate both track and facing. It may be acceptable to rely on placement to indicate one or the other; it may be fine to use placement to assist either, in combination with other visual cues.

Type

There are 6 types of signal; each has a distinct effect. When I'm trying to figure out why my trains are stalled, I want to look over all my signals and quickly find the one that I placed wrongly. Clicking on a signal to see its type is useless for this.

Indication

Any signal may indicate one of three things to the (hypothetical) engineer of a train in his cab: 'proceed', 'stop' (and wait), or 'swap' (swap end-for-end or turn around). Indications are dynamic, meaning that they change depending on track conditions; but some indications are static, such as that given a train approaching a one-way path signal from the back ('swap'). I'm mostly concerned with dynamic indications; static indications can be deduced from facing and type.

I have heard it stated, several times stridently, that indication is of no interest to the player. Well, I will concede that anyone who says so, probably has no interest.

It should be clear that the entire reason that a signal exists, ingame or prototype, is to indicate. A signal that indicates nothiing is useless and meaningless; a signal whose indication is completely static can be replaced by a wooden sign. We build signals to present a dynamic indication to approaching trains.

One way to tell if a signal is behaving as it should is to see how it is behaving. My natural approach in debugging anything is to see what it does before trying to change that.

Indications also reinforce other signal aspects. A signal that usually indicates 'stop' is probably a path signal; if two signals constantly change indication together, then it is likely that they are some sorts of pre-signals. If a train approaches a tangle of track surrounded by several signals and one of them changes from 'stop' to 'proceed', then returns to 'stop' after the train passes, this not only suggests that the signal is a path signal; it also tells that this is the signal on the track where the train was and that the train approached it from its front.

Indeed, if a network is heavily frequented by passing trains, one might almost dispense with every other display of aspect -- track, facing, type -- and rely entirely on dynamic indication to reveal them, by patterns of change.

Indications are essential and will, on no account, be ignored in the design of bigsig.

Gold Standard

I will consider all goals met when the average player can correctly identify all aspects of every signal when the map view is zoomed out by one step.
-Xiong
User avatar
changnian
Engineer
Engineer
Posts: 26
Joined: 12 Oct 2010 08:23

Re: bigsig (schematic signal set) [final design]

Post by changnian »

final design; on grass background for demonstration only
final design; on grass background for demonstration only
bigsig-004-just-grass.png (11.15 KiB) Viewed 6216 times
final design; on magic pink background (#ff00ff)
final design; on magic pink background (#ff00ff)
bigsig-004-magic-pink.png (7.77 KiB) Viewed 6216 times
-Xiong
gross
Engineer
Engineer
Posts: 1
Joined: 22 Aug 2011 19:31
Location: Moscow, Russia

Re: bigsig (schematic signal set) [final design]

Post by gross »

I've assembled newgrf based on Xiong's graphics. It doesn't contain any PBS, but only usual and pre signals.
Attachments
bigsig.grf
Assebled NewGRF based on bigsig-004-magic-pink.png by Xiong Changnian. Under CC-BY-NC-SA 3.0
(10.16 KiB) Downloaded 129 times
Post Reply

Return to “Graphics Development”

Who is online

Users browsing this forum: Google Adsense [Bot], Morgs and 12 guests