I'm new to gosu and have some experience with sdl and opengl. I don't really have an end goal in mind; I'm just curious what I could do with Gosu. Perhaps something simple like Alpha Centauri cuz that game was bawss!
so i've been working on some isometric tiles and here a sample of what was generated supplying random tiles and elevations:
The server and client appear to be communicating data correctly. The blending functions all seem to be in order!
But when I zoom out and start changing elevations . . .
. . there are black triangles scattered about, and can't find where in MY code those are coming from. I'm sure it's just something I overlooked (isometric views are not as intuitive as I had originally intuited), so I'll keep looking. In the mean time I was curious if anyone else has encountered this sort of thing using the draw_as_quad function.
So are these black thin lines between tiles intentional? I am surprised that they're there :O
Also no idea about the black triangles. If you can build a small test case and it turns out that
draw_quad cannot handle some coordinates well, I'll gladly look into it. In the meantime, can you add some runtime tests to make sure that the corners of adjacent tiles always match?
those black lines are not intentional. i suspect they are some error with my home-brewed scaling function. Because my blending function is operating on every pixel of each tile, I need to employ some mip-mapping to reduce the time it takes to complete based upon the number of total number tiles being displayed at any time. Smaller tiles are not just scaled by gosu, but are using lower res versions of the tileset. without this scaling function there are no little black lines; although it would take forever to blend up to four 1024x1024 textures per tile.
That said, if i do fix this scaling function, I'd likely want to switch between the two versions, as sometimes it might be handy to see the boarders between tiles, depending on what sort of game comes out of this. 'There are no mistakes, only happy accidents!'
I'm interested how others might approach scaling/mip-mapping? here is mine, belongs to an instance of Surface class, and takes a float between 0.0 and 1.0 as input:
nw = (@w*n).to_i
nh = (@h*n).to_i
skipw = (@w/nw)*4
skiph = (@h/nh)*4
pixie = ''
pixie << @pixels[((y*skiph)*@w)+(x*skipw),4]
@w = nw
@h = nh
@pixels = pixie
pixels, here, being the same as blob.
I have not built mip-maps before, but I'd try to generate the different mip-map levels during development using RMagick or some other tool. Less code, better results, because it does not simply skip pixels :)
(Or maybe Gosu should just let you enable mip-mapping with a flag...but so far this has not been a common request.)
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill