Started by cpcitor, 23:43, 20 October 13
0 Members and 1 Guest are viewing this topic.
QuoteSo, how's it done? Well, briefly, they're constructed using SINE tables to calculate the perspective and to give the illusion of depth. Perhaps the space-ships look a little squashed from some angles and the point of infinity is pitched a little close owing to the compact size of the programmer's universe, but these are minor criticisms.
QuoteAs for the 3D shapes, they're all constructed in high memory and transferred onto the screen using another version of the Stack method. In fact, he uses nearly all the alternate registers except for the two HL pairs.
Quote from: MaV on 12:30, 24 October 13I'm not partial to Starion. The animation is smooth but the wire-frames look too distorted. I suspect the point of infinity for the perspective is too close to the viewer, since the far side of the wire frames look much too small in comparison to the parts that are closer to the viewer. The best example is the ship itself when it is rotating in the main menu (I think).I assume that was also done to avoid hidden line removal (HLR) which is a bit costly, and to up the number of vertices. Proof of that is the complex wireframe of the ship.
Quote from: MaV on 12:30, 24 October 133D Starstrike has done a better job but still has the problem that without HLR, it is up to the viewer to discern which points are far away to establish a sense of perspective. Point of proof, look away then back at the screen and see how quickly you figure out the object's position in 3D space.
Quote from: MaV on 12:30, 24 October 13The one game that did this right is Starglider (and thus arguably all games with proper surface rendering like Starstrike II and the games by Incentive software).
Quote from: MaV on 12:30, 24 October 13The article mentions some techniques (stack method, sin/cos tables) which may have been new and not well-known in '85/'86, but I guess they can be called trivial today. I don't know anything about "high memory" on the ZX Spectrum but it is safe to assume that this is nothing new.
Quote from: cpcitor on 23:29, 24 October 13Focal lengthWhen doing 3D computation rigorously you have to know the distance between the screen and the viewer's eyes.In photography it's called the focal length, see http://en.wikipedia.org/wiki/Focal_length#In_photography .In practice it is unknown and variable as you move your head. Instead, a constant number is used.Small focal lengthWhat you describe is the result of choosing a too small constant.The picture below illustrates. The satellites have very different apparent sizes due to the choice of a small focal length.
QuoteBesides this, the shapes are mathematically correct, in the sense that the program uses correct 3D projection equations, not crude approximations.
QuoteAlso, when really close to some object, e.g. time warp, lines extending outside the screen disappear. Example below: first image is correct, second misses rightmost edge of pentagonal shape.
QuoteMy conclusion is that very probably, Starion is optimized to death with a great mastery of computation, precision and error propagation, and with good compromises between game parameters (focal length, world size, etc) to make limited-precision and high-speed computation viable.
QuoteYes, from memories Starglider had good geometry.Elite had hidden line removal (within an object only, no handling of superposition of objects) which make a good rendering, too. The framerate was good for an 8-bit and the feeling of an actual immense universe made Elite a great game (though very hard to start with, so easy to wreck your ship on space station entry).
QuoteAll those don't have the incredible framerate of Starion, hence my conclusion above.
QuoteYes, that's why I created this thread in the first place: to see if someone had already done some analysis (which I'm not planning to do.)
Quote from: arnoldemu on 11:36, 25 October 13For my 3d I don't clear the screen. I draw black lines over the lines I drawed before.
Quote from: TFM on 19:22, 25 October 13Use a routine which puts whole &00 bytes in the V-RAM instead of drawing a line, you will get a BIG speed up that way. You can basicly use the draw routine's algorithm, but won't need to mask pixel.
Quote from: arnoldemu on 11:36, 25 October 13For my 3d I don't clear the screen. I draw black lines over the lines I drawed before - same method as Elite does on the BBC. If you always draw using the same function, draw from the same coordinates then your line draw code will draw over the top always.
Quote from: TFM on 18:08, 31 October 13Of course there is a point when the number of objects reach a threshold and you break down to 25 fps.
Quote from: MaV on 18:31, 31 October 13And that's the point I'm most interested in. I've been pondering the same solution - only clear what you need to clear - and I'm searching for one with the smallest trade-off.
Quote from: cpcitor on 20:43, 31 October 13How about doing it only once and remember the list of bytes affected by the lines ?To erase just write 0 to the list of affected bytes.
Quote from: cpcitor on 20:43, 31 October 13Interesting.So you're still doing bresenham twice.How about doing it only once and remember the list of bytes affected by the lines ?To erase just write 0 to the list of affected bytes.Are there proven circumstances where not doing Bresenham + pixel to bytes conversion is faster ?
Page created in 0.106 seconds with 27 queries.