Dark Bit Factory & Gravity
GENERAL => Projects => Topic started by: mike_g on August 20, 2007
-
Ok, it looks like I have given up on this for the time being at least. So heres what I got of my raycaster. It includes an executable version and Blitz source code. Theres a level editor with it so you can create you own levels and also indoor and outdoor effects. Theres a slight bug with the floor casting, but the horrible clipping I had before problem is fixed.
Download link (http://mike_g.sitesled.com/Raycast.zip)
-
Nice stuff there dude.
-
Thats impressive thanks for sharing the source :D
-
Thanks :)
-
@mike_g:
Very nice! Btw, outdoors runs @60 fps here... while indoors runs only @30 fps... i think it slows down, in fact of the lighting / distance of objects where you are trying to add the fake lighting... If so, you should try to optimize the code for this... Maybe you can increase the speed a bit while just creating the lighting/distance (also color changing = darker for bigger distance) with bit shifting for each color or possible with just a pre-generated color table (255 steps) ^^ Good luck! Anyway nice work
-
Yeah, the shading really slows things down. I havent got around to exiting each the ray when it reaches the a point where things would be black. That would speed it up quite a bit in open spaces, which is where the real speed drainage is. Lighting colour tables would also be a good idea, I might have a go at it. Cheers.
-
Using MMX you could draw 4 pixels at once... so you could speed up your raycaster a lot... just another idea to improve the speed.
-
you can use integers to do the shading instead of converting to float and back again:
shade%=(integer value from 0-256)
;separate each component, multiply by shade and remove the low 8 bits of the result.
r%=((col and $ff0000)*shade)and $ff000000
g%=((col and $00ff00)*shade)and $00ff0000
b%=((col and $0000ff)*shade);and $0000ff00 ; (it's all gonna be shifted down anyway so 'And' not needed here
;Or the remaining high 8 bits of each result and shift down 8 bits
col=(r or g or b)shr 8
I'm not 100% sure if the red part will be right when using signed integers or if there's an unsigned datatype in blitz so you might need to do something like this instead:
shade%=(integer value from 0-256)
;separate each component, multiply by shade and remove the low 8 bits of the result (red shifted down 8 first).
r%=(((col and $ff0000)shr 8)*shade)and $ff0000
g%=((col and $00ff00)*shade)and $00ff0000
b%=((col and $0000ff)*shade);and $0000ff00 ; (it's all gonna be shifted down anyway so 'And' not needed here
;Or the remaining high 8 bits of each result and shift down 8 bits
col=r or ((g or b)shr 8)
If the first bit of code works, it is also possible to do the shading on the red and blue components at the same time.
-
Haha, nice stonemonkey :) Yeah, I could really do with getting rid of those floating point calculations. Theres no way of unsigning integers in Blitz, but I imagine the red component should be fine as it uses 32 bit colour. I'll try out your suggestion.
-
When you're dealing with 32 bit signed integer variables, the last bit (bit31) is the sign, in the first example i gave the red can end up needing that bit. If that does cause problems the 2nd example should still work fine.
-
ATTENTION - BUG!
I cant test the source because i dont have FB not know how to code with.. but this is wrong:
shade%=(integer value from 0-256)
integer value must be from 0 to 255 instead up to 256 !!!
-
Sorry va!n, that just means shade has to be an integer value in the range 0 to 256.
I know it's strange that it's not 0 to 255 but it is 0 to 256. Sometimes that range isn't possible (if it's a byte) so you can add 1 as an integer before doing the shading so it's the range 1 to 256 so there's no loss of information but an integer can work in that range.
(num*0)shr 8=0
(num*256) shr 8=num
but also:
(num*1)shr 8=0 for any 8 bit value
and:
(255*255)shr 8=254 (slight loss)
-
Vain: Unfortunately, I dont think you can use MMX features in Blitz. Would be nice if it was possible tho :-\
Stonemonkey: I got it working. Thanks. Thats quite cool use of binary operators :) So far I'm having no problem with the first version, but my textures don't have a whole lot of red in them. I tried the second version too, which for some reason came out with a blueish tint. It looked kind of cool tho. I think my FPS only went up by 1 or 2, but I guess thats a reasonable increase when I'm getting 10-12 fps in 640*480 ;D
TBH the real speed killer is the amount of times my prog is checking points on the rays. If I check them less, theres a whole load more speed, but everything comes out very blocky.
-
Well, if the first version turns out to work (don't understand the bluish tint in the second though) then this should work too. You can do the calculations on both the red and the blue components together and only have to separate out the green.
shade%=(integer value from 0-256)
r_b%=((col and $ff00ff)*shade)and $ff00ff00
g%=((col and $00ff00)*shade)and $00ff0000
col=(r_b or g)shr 8
It most likely won't make any difference to how well your code runs though but in things i'm working on atm I have a huge amount of shading and blending where it might make some difference.
-
I thought it might work like that when you said its possible to do the red and blue at the same time. Not ideal for blitz with the signed bit thing, but I made a colour blend function in C using all the stuff you showed me. Thanks :)
[edit] Yeah and that blueish thing must have been something I got wrong before. [/edit]
-
You don't have to worry about the sign, SHR in blitz is an unsigned shift which doesn't duplicate the sign bit - if you want that you have to use SAR instead.
a%=$ff0000
b%=256
Print Hex$(a*b)
answer% = (a*b) Shr 8
Print Hex$(answer)
answer% = (a*b) Sar 8
Print Hex$(answer)
Repeat
Delay 100
Until KeyDown(1)
Jim
-
Oh, cool. I'm sure I saw SAR in the help file, just never paid much attention to what it did. Now I know what it does its actually quite useful. Thanks jim.