what part in starstryck is an animation?
category: general [glöplog]
p01: The hemispheres should still be connected around all the four edges. Your method would only work for one of the edges at the time.
p01: You'd still have problems at the poles, but I guess you could make that work. With a big texture.
You could map it to theta=v, phi=u. That gives you a single seem at theta=0, and nasty warping at the poles. But you could map a textured cube onto that.
yeah, but that wastes texture space vs precision like no tomorrow, and you'll have to create huge textures to make it look good.
using theta=v, phi=u, the texture(s) have to be polar ( no big deal ) to map correctly the poles.
doom, as for cache efficiency in grid tracers: it's pretty good. span-based methods have performance that varies a lot with texture orientation; one grid block always has both "mostly horizontal" and "mostly vertical" steps - so cachewise, the best case (not rotated at all) is slightly worse than with a span-based renderer, but the worst case (90° rotated) is way better, and overall variance is usually less, which is a good thing.
p01: yeah, but for a 256x512 texture for instance, the texels-rows at the top and bottom (close to the pole) are crammed into a much smaller screen space area than those at the center.
kusma: True :\ the polar distortion of the texture will require a rather big resolution to be crisp.
ryg: Good point, I never really realized that.
kusma: that was the trick in pascal's original cache optimized rotzoomer - it just rendered in 16x16 pixel blocks (IIRC) instead of line by line. and after he had that code, he realized that it'd be piece of cake to use the same inner loop, but assign texture coordinates to each block (after all, calculating the deltas for a 16x16 block is a piece of cake), and tada, the grid wobbler was born :)
ryg: Aha! I never knew that, cool to hear the history!
Working on tiles allow a lot more calculations that should be per pixel to be done per tile without much loss in quality; mip-map selection for instance, or better - performance trilinear filtering with innerloop selection on a per block basis. Adaptive subdivision allows for even more cool things, but then the amount of inner-loops kinda explode, and you'd need some kind of cached innerloop-generator or something to get proper speed without wasting memory like a madman ;)
Ahwell, perhaps I'm a bit more worried about memory-usage since I do GBA-stuff.
Working on tiles allow a lot more calculations that should be per pixel to be done per tile without much loss in quality; mip-map selection for instance, or better - performance trilinear filtering with innerloop selection on a per block basis. Adaptive subdivision allows for even more cool things, but then the amount of inner-loops kinda explode, and you'd need some kind of cached innerloop-generator or something to get proper speed without wasting memory like a madman ;)
Ahwell, perhaps I'm a bit more worried about memory-usage since I do GBA-stuff.
to disable cache for textures, you just have to mark these memory pages as not-cacheable in the mmu tables.
but the fastest thing to do is to just tile the drawing or tile the texture, no need to do both :)
for a texture tiling mapper, take a look at the end of this thread on ada
but the fastest thing to do is to just tile the drawing or tile the texture, no need to do both :)
for a texture tiling mapper, take a look at the end of this thread on ada
also available: 0 divides per triangle rasterizer equations
Winden: But don't you pay for just using the MMU?
MMU structures are cached on the Adress Translation Cache, which has 256 entries for a total of 1 megabyte of mapped data. you could also use a data TTR to setup a big area as uncached without using up any MMU pagetables for this.
insert coin to load bank#FF to segment 00!
anyway, why would you? a tiled tmapper (either tiled texture or tiled rasterization) with cache is normally faster than a sequential tmapper without cache, and writing one isn't exactly rocket science.
the datacache is a small 8k with 4way, so if you need to handle complex enough structures it may be a win to keep them cached instead of the texture. see for example having a global per-scanline routine instead of a per-triangle one: you may be better of with keeping the active span lists on cache instead of the textures which you are going to be switching around a lot more.
Quote:
It's all about good, hand-crafted graphics and design, strong colours and strict moderation in the use of "psychedelic" elements. TBL are very good at that, and most people who make PC demos aren't.
See? Your definition of "better" is broken. Just like Sparcus said, it's the people, not the hardware.
Argh, all that 3d talk makes me want to pick up my GBA engine and finish it :o
Shifter FFS that's what I'm saying. Current state of affairs, an Amiga demo can be "better" than a PC demo, and vice versa. It has everything to do with graphics, music and style, and fuck all to do with how many triangles you can push through the pipeline. I think there's a lot more to it but that's not the popular opinion and it's not what I'm saying.
You really need to take over a robot with a better argument.
Who's arguing?
Graga: Then do that, fuckwad! Give more GBA-demo for futur of bettar scene!
Of course! I just need to do 3 shitty math assignments, then score a girl at the october-fest next friday, and then fix my guitar. Then I'll play it. Then I'll start coding! I promise that I'll concider it!