free directional madness, or evil x-interpolator bugs
category: code [glöplog]
I'm trying to code a simple DOS demo in Watcom C, and I coded a free directional planes effect. Currently it works at 40x100 grid (interpolated to 320x100 and displayed in 320x100@60Hz tweaked mode 13h), but...
my horizontal grid-interpolation routine (fdInterpolateHorizontal() in sourcecode) produces some bugs when texture coordinates wraps around: i.e if two nodes contain 0x20 and 0x40 it works fine, but when they contain 0xF0 and 0x00 it counts backward and distorts texture coordinates. SHIT!
Currently it looks like that:
(notice that interpolation bugs at texture eges, and yes, ugly XOR pattern :)
Source code and executable: http://rghost.ru/7tnPmhcwh
Any ideas? :)
my horizontal grid-interpolation routine (fdInterpolateHorizontal() in sourcecode) produces some bugs when texture coordinates wraps around: i.e if two nodes contain 0x20 and 0x40 it works fine, but when they contain 0xF0 and 0x00 it counts backward and distorts texture coordinates. SHIT!
Currently it looks like that:
(notice that interpolation bugs at texture eges, and yes, ugly XOR pattern :)
Source code and executable: http://rghost.ru/7tnPmhcwh
Any ideas? :)
but it looks better like this! it's almost glitch art!
You can read this on how it's solved in scanline renderers: https://msdn.microsoft.com/en-us/library/windows/desktop/bb206256%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
Maali, yep! :D
Gargaj, erm...it describes a texture wrapping method in D3D, however i'm doing all stuff in software...thanx anyway :)
Gargaj, erm...it describes a texture wrapping method in D3D, however i'm doing all stuff in software...thanx anyway :)
without spending too much time thinking about this, but if you keep the values in ux0 ux1 etc. left aligned (so they occupy the higher order bits), do the subtraction and then do a right shift to get the fixed point format you want, the sign extension of the right shift should solve your problem (unless you zoom out too much and get kinda aliasing problems, but that would be a general problem at some point).
wormsbiysk: the principle is the same though - you test for the "shortest distance".
use signed (short) ints as texcoords and pow2 map; solved.
Quote:
use signed (short) ints as texcoords and pow2 map; solved.
YES! it works now properly! (currently at 60fps only on P250MMX (83x3.5), shame :), trying to optimize it)
40x100 grid sounds huge to me. You can easily make a silky smooth 320x200 version with 8x8 blocks (so grid size of 40x25).
yep, now i'm using 40x25 grid and tracing takes about 40-50 scanlines but grid interpolation takes one entire frame(!) in 320x200 and texturing takes another 150-200 scanlines.
so it worka only in two frames = 30fps in 320x200 :(
so it worka only in two frames = 30fps in 320x200 :(
I haven't looked at the code but that's slow as shit of course:
- any floats involved at any point? kill 'em
- 32-bit color? use mmx
- poorly cached memory reads?
- no divs!
etc.
- any floats involved at any point? kill 'em
- 32-bit color? use mmx
- poorly cached memory reads?
- no divs!
etc.
Second try: http://rghost.ru/8HFpsSptB (and red rasterbar)
compiler options:
and profile log:
(don't mind sincalc and texture building routines as they are called once in beginning ;)
As I can see the most CPU hogging procedures are fdInterpolateHorizontal and fdDrawPlanes which I think just suffers from cache misses.
no, 8-bit color, I can use mmx of course but it will cause troubles with dosbox
two float divs in tracing routine (but processed for each node in grid)
compiler options:
Code:
wcl386.exe freedirf.c -zp16 -fp5 -ox -or and profile log:
Code:
164374 1040 fdNormalize
595449 1 fdInterpolateVertical
2187873 1 fdInterpolateHorizontal
17818894 1 fdbuildSinTable
107057 1040 fd3dRotate
2773401 1 fdbuildTexture
754647 1 fdCalcPlanes
1595055 1 fdDrawPlanes
37364119 1 main
(don't mind sincalc and texture building routines as they are called once in beginning ;)
As I can see the most CPU hogging procedures are fdInterpolateHorizontal and fdDrawPlanes which I think just suffers from cache misses.
Quote:
- 32-bit color? use mmx
no, 8-bit color, I can use mmx of course but it will cause troubles with dosbox
Code:
- no divs!two float divs in tracing routine (but processed for each node in grid)
jesus christ why all the tables? only to blit it in drawplanes? :)
get rid of 'em, no wonder with all those temporaries and pointers you're giving that x86 a hard time
1. calculate grid (straightforward and simple)
2. bilerp it *directly* to screen
get rid of 'em, no wonder with all those temporaries and pointers you're giving that x86 a hard time
1. calculate grid (straightforward and simple)
2. bilerp it *directly* to screen
in one word: simplify
you're touching way more memory than necessary to get it done (gargaj can we have a fucking edit feature here already if you can find the time in between polishing your ferrari?)
No.
asshole
I've heard Pouet is open source now!
well, almost :D
anyway, thanx to all :)
anyway, thanx to all :)