Dear Kevin,
I recently purchased PlayBasic2DLL and it's new to me.
I was wondering if you could refur me to all articles that are about it. I found a few just not sure if it's all the info I could see about the subject.
Also could you please post a beginners tutorial for the operation of this tool. I would love to know how to operate it and use it to my behave.
The basics would be great for a start then maybe I can move on to the more complicated topics.
Thanks
ScottieB
Well, Today I read a few articles to get me started they were very informative.
I have some questions though. I bought this program because I wanted mainly to increase graphics performance.
The slight drawback so far is I don't know much about poking and peeking within video memory or image memory.
I wanted to know if you could teach me a bit about it? I would love to to have very fast plotting and reading of pixels so I can do some more fancy graphic demos.
Even a fast screen fade would produce a red alert demo. While fast plotting could be screen desovles. Not to mention alot more.
fast reading could increase speeds of raycasters ect... If you could cover how so basic drawing routines could be optimized many new thing could be more possiable.
please this is why i purchased it in the first place. any help would be greatly appriciated.
Big Thanks
ScottieB
The package comes with html documentation, it's not brilliant, but it does include a getting started section and bunch of info on stuff like raw pixel writing (Although you can find that in the PB manual). However, since PB2DLL is an extension package, it assumes the user knows their way around PlayBASIC fairly well.
To a build a DLL from PlayBASIC source, you first write the library code as normal. When it's complete tested and ready to deploy. Then you fire up PB2DLL, then compile the source into a DLL. It's pretty much one step process. The tool creates a DLL and a playbasic (PBA) source file that has the DLL's bindings in for you. So use the library in your code you copy those files to you project and #incllude the source and you're way.
A PlayBASIC library is simply a source file (PBA extension) with a collection of PlayBASIC functions in it. The functions can have set up code, but it should not contain a 'main' loop like a normal program. The main point is that your library code should compile on it's own, away from your project. So there can't be any dependencies and a programmer could just #include at the top of any program and start using the functions.
[pbcode]
// --------------[MAIN.PBA] -------------------------------------------
//
#include "MY-LIBRARY.PBA"
TestImage=DLL_MakeColouredImage(256,100,$00ff00,2)
drawImage testimage,100,100,False
Sync
waitkey
// --------------[MY-LIBRARY.PBA] -------------------------------------------
// To build a DLL you first write your library. When it'd complete
// tested and ready to deploy.
// Exported DLL functions need to prefixed with DLL_ These are functions
// that will be visible from outside of the function. So everything
// else will be private and invisible the user of the library.
// Example
Function DLL_AddIntegers(A,B)
Result=A+B
EndFunction Result
// Make colour image. using direct memory access.
Function DLL_MakeColouredImage(Width,height,Colour,Format)
if Width>0 and Height>0
ThisImage= newImage(Width,Height,Format)
OldSurface=GetSurface()
rendertoimage ThisIMAGE
ThisRGB=Point(0,0)
Depth=getImageDepth(ThisIMAGE)
Lockbuffer
; read a pixel to make sure the GFX engine is pointing at this
; surface, it's possible it may not be after a LOCK
ThisRGB= Point(0,0)
ImagePointer = GetimagePTR(ThisIMAGE)
; Get the number of pixels that make up 1 row of pixels in this image
; different colour formats mean the row width will differ. It's best
; to never you know the pitch/modulo of the surface.. Always query it
ImagePitch = GetimagePitch(ThisIMAGE)
Select Depth
// ---------------------------------------------
case 32
// ---------------------------------------------
For YLP =0 to Height-1
// Compute address in memory of this row of 32bit pixels
RowAddress = ImagePointer + (YLP* ImagePitch)
For XLP =0 to width-1
PokeInt RowAddress, COLOUR
// Move to the next pixel across the row
RowAddress+=4
next
next
endselect
unlockbuffer
rendertoimage OldSurface
endif
EndFunction ThisIMage
[/pbcode]
The above mock up, shows how to manually address pixels in a 32bit image. For understanding how images work, this isn't a DB2DLL thing, it's a PlayBASIC thing. There's many many example of here and in the documentation. Here's one from 2009 PlayBasic Optimization Tutorial - Cross fade Methods (http://www.underwaredesign.com/forums/index.php?topic=2890.0) which goes through a few cross fading ideas.
Related Links:
* 2D Shapes - Making a library for PlayBASIC2DLL (2021-01-15) (https://www.underwaredesign.com/forums/index.php?topic=4571.0)
* PlayBASIC To DLL (Development Blog) (http://www.underwaredesign.com/forums/index.php?topic=4105.0)
* Tutorial - A Crash Course In BASIC program Optimization (http://www.underwaredesign.com/forums/index.php?topic=2548.0)
Thanks Kevin that's a big help.
Is there also a way to read pixels fast? (PeekInt)???
You said that image writing is mostly a playbasic thing not a playbasic2dll thing so where else can I look to learn more about this?
I not finding many examples only a few but I'll keep searching anyways.
Any more information you can give me would be nice even if its how fast can we clear the screen with a color consecatively.
This sounds like I need to learn to look into image addressing peeking and pokeing within image memory at proper addresses.
I've never gone that deep with image manipulation. It also sounds like I need to know about image structure and how that is comprised as
I don't think I want to get it fouled up when messing with memory addressing?
Can you give a good explanation to what is going on here? and how the bytes are arranged? A good run down on the structure of this would be nice.
This looks to be a advanced topic not for anyone that does not use playbasic alot.
What I sort of get right now is where looking a pointers that show use the starting memory address and work from there byte wise either looking or putting our new
correct bytes directly into image memory. I'm just not sure how to do this correctly without not knowing about proper structure on what this constists off.
And I'm quite sure I don't want to get it wrong so good understanding is a must or it could potentallly hurt program or maybe computer.
So...
Is there a way you could explain this well in simple and consise words without being overly diffucult???
Also...
It seems as though we need to know hexcodes for colour information and what about about floodfills of sreen or even arrays when were dealing with search algorytms??
I gueess this kind of stuff also could relate to memory addresses within arrays correct??? Optimaztions like this could really boost playbasic program proformance. So...
I queess I like to know how this protains to arrays as well?? exspeciallly if A.I. Algos parents and childs nodes could be executed faster.
After searching around a bit I came up with these by you.
ScreenWidth =640
ScreenHeight =400
openscreen ScreenWidth,ScreenHeight,32,1
Dim Ptr as pointer
if GetScreenDepth()=32
Lockbuffer
Ptr =getimageptr(0)
Pitch =getimagepitch(0)
Depth =getimagedepth(0)
For ylp=0 to ScreenHeight-1
Dim LinePtr as integer pointer
LinePtr =Ptr+Ylp*Pitch
For xlp=0 to ScreenWidth-1
*LinePtr=rgb(ylp,xlp*ylp,xlp)
LinePtr=LInePtr+1
next
next
UnLockbuffer
endif
print int(ptr)
print Pitch
print depth
sync
waitkey
and... *********
openscreen 800,600,32,1
lockbuffer
Address =getImageptr(0)
Picth =GetIMagePitch(0)
Depth =GetIMageDepth(0)
if DEpth=32
for x=0 to GetSurfacewidth()-1
PokeInt Address+(x*4),rndrgb()
next
endif
unlockbuffer
Sync
waitkey
This looks too be sort of what I'm looking for but also with reading and colour capiablities.
Any suggestions since these are old posts????
A few examples would also be super great.
Thanks
ScottieB
An image is just a 2D array of colours, stored Width by Height. The number of bytes per colour can range from 2 bytes per pixel (in 15 or 16 bit modes), to 3 bytes for 24bit and 4 bytes for 32bit.
Here's some quick links,
* PB2DLL - Water Demo (http://www.underwaredesign.com/forums/index.php?topic=4196.0)
* Sinus Example (http://www.underwaredesign.com/forums/index.php?topic=4105.msg28323#msg28323)
* Image data file save-load (http://www.underwaredesign.com/forums/index.php?topic=3621.0)
* Low Level Pixel Manipulation Example (http://www.underwaredesign.com/forums/index.php?topic=3945.msg28257#msg28257)
* Screen/Image Direct Memory Access (http://www.underwaredesign.com/forums/index.php?topic=1825.0)
* Encode File / Hide File Contents / Xor Encryption (http://www.underwaredesign.com/forums/index.php?topic=4289.0)
* Async Flood Filling & Flood Filling Optimizations Example (http://www.underwaredesign.com/forums/index.php?topic=4261.msg28682#msg28682)
Here's an image from the GetImagePtr there's nothing more to it.
[pbcode]
Cls RGB(0,0,255)
; create four images in each in a different video format
w=128
h=256
CreateFXImageEx 1,w,h,15 ; 15bit version
CreateFXImageEx 2,w,h,16 ; 16bit version
CreateFXImageEx 3,w,h,24 ; 24bit version
CreateFXImageEx 4,w,h,32 ; 32bit version
; Draw them to the screen
Xpos=60
Ypos=50
For i=1 To 4
FillImage(i)
Text Xpos,Ypos, "Address:"+Str$(GetImagePtr(i))
Text Xpos,Ypos+20," Pitch:"+Str$(GetImagePitch(i))
Text Xpos,Ypos+40," Depth:"+Str$(GetImageDepth(i))
DrawImage i,Xpos,Ypos+60,false
Xpos=Xpos+w+40
Next
; show the screen and wait for user to press a key
Sync
WaitKey
Function FillImage(ThisImage)
RenderToImage ThisImage
LockBuffer
Address =GetImagePtr(ThisImage)
Pitch =GetImagePitch(ThisIMage)
Depth =GetImageDepth(ThisImage)
Colour=0
For ylp=0 To GetImageHeight(ThisImage)-1
Colour2=colour
For xlp=0 To GetImageWidth(ThisImage)-1
PokePixel(Address,Pitch,Depth,Xlp,Ylp,Colour2)
Colour2=Colour2+1
Next
Colour=RgbAlphaAdd(Colour,$020101)
Next
UnLockBuffer
RenderToScreen
EndFunction
;*=------------------------------------------------------=*
; >> Generic Poke Pixel Routine <<
;*=-----------------------------------------------------=*
Psub PokePixel(Address,Pitch,Depth,Xpos,Ypos,Colour)
If Address<>0
Select Depth
Case 15 ; 16bit RGB 555 format
R=LSL16((RgbR(colour) & $f8),7)
G=LSL16((RgbG(colour) & $f8),2)
B=LSR16((RgbB(colour) & $f8),3)
pokeword Address+(ypos*pitch)+(xpos*2), R | G | B
Case 16
R=LSL16((RgbR(colour) & $f8),8)
G=LSL16((RgbG(colour) & $fc),3)
B=LSR16((RgbB(colour) & $f8),3)
pokeword Address+(ypos*pitch)+(xpos*2), R | G | B
Case 24 ; 24bit RGB's
R=RgbR(colour)
G=RgbG(colour)
B=RgbB(colour)
Address=Address+(Ypos*pitch)+(xpos*3)
pokebyte Address,R
pokebyte Address+1,G
pokebyte Address+2,B
Case 32 ; 32bit RGB either XRGB (-888) format or (ARGB 8888) format
pokeint Address+(Ypos*Pitch)+(Xpos*4),COlour
EndSelect
EndIf
EndPsub
[/pbcode]
Most imformative,
Thanks for all the help.
I'll study these over.
Any ideas on how we handle a grayscale image / 256 coloured images (0-255) like in a heightmap?
I found this very interesting. I'll have to try some testing.
gray scale's are just normal images. In an 8bit one you just take either the R,G or B from the point and use it as height. in 16bit versions you'd take G,B as the height.
Been trying out lots of different things.
I finally figured out some new stuff.
Hey, I'm having trouble with FastDot And FastPoint on Images.
I Got Screen O.K. but whats the proper way on an image? Is There a difference with FX Images? And Yes, I had to seed them.
This morning I got FastPoint And FastDot with images using NewImage and CreateImage still not sure about FX And AFX though?
I also was looking at your palette mapping library where can I get more info? Like whats the commands in the include?
Will palettemapping make me palettes with a whole range like a fire palette with gradients from like say white to yellow to orange to red to black blending as it goes or
is that another command for makeing palettes? I deffinately see your doing palette rotation!
The screen is image 0, so there's no difference in between and image and screen. All you do Render to the surface, lock it, mod it , unlock it.. Actually my previous post shows exactly how to this. You find lots of examples using LockBuffer, Just search for the forums.
The palette mapping commands are all listed in the help..
Palette Mapped Example (http://www.underwaredesign.com/forums/index.php?topic=4353.0)
Yes, I can read/write fastdot and fastpoint to images but crashing when I do FXImage AFXImage any ideas?
I guess thats difference between video memory and computer memory but is there still a way?
FX And AFX are usually faster too.
Quote
Yes, I can read/write fastdot and fastpoint to images but crashing when I do FXImage AFXImage any ideas?
No, that's not normal. The example in these thread is reading/write to FX images. So why not post your code ?
[pbcode]
ThisImage = NewImage(200,200,2)
rendertoimage ThisImage
lockbuffer
ThisRGB=Point(0,0)
for ylp=0 to GetImageHeight(ThisImage)-1
for xlp=0 to GetImageWidth(ThisImage)-1
ThisCOLOUR = rgb(YLP,0,XLP)
FastDot xlp,ylp, ThisCOLOUR
next
next
unlockbuffer
rendertoscreen
drawimage ThisImage , 200,200,false
Sync
waitkey
[/pbcode]
Quote
FX And AFX are usually faster too.
please read the images tutorial in the help. Go to Help -> About -> Images
I guess your right.
I must of been messing something up or I was a bit confused.
Thanks for the clearification.
These have been the start of some really cool speedups.
I learned a bunch of commands in the process.
Thanks!
That will make for better programs.
Do you feel like getting into arrays and how these can also be accessed differently much like we used poke and peek on video and images?
Some speedup for arrays persay? LIke in the playbasic2dll they start to mention it but can you put it alittle better or clearify?
Thanks Again
ScottieB
All this stuff is there covered in the PlayBASIC manual. See Help->Memory Management -> GetArrayPtr in the help files for search for in the examples packs and here on the forums.
none the less, here's cut'n'paste from the help.. as for where and what you'd use direct access is up the programmer. It appears in lots of my examples, so my suggestion would be study them.
[pbcode]
; =============
; Part #1
; =============
; Create an Array Called Table()
Dim Table(10)
; Store values in this array
For lp=0 To 10
Table(lp)=100+lp
Next
; =============
; Part #2
; =============
; Get the Base Address of this array
Address=GetArrayPtr(table())
; peek the array memory and show the elements
ShowArray(Address)
; manually poke some new values into this arrays memory
Print "Poking Data Directly Into This Arrays Memory"
DataAddress=Address+pbarraystruct_size
For lp=0 To 10
pokeint Dataaddress+(lp*4),2000+lp
Next
;Show the array memory again
ShowArray(Address)
Sync
WaitKey
Function ShowArray(Address)
Print "Display Array Data"
DataAddress=Address+pbarraystruct_size
For lp=0 To 10
Print peekint(Dataaddress+(lp*4))
Next
EndFunction
[/pbcode]
Here's a look at what I'm now trying to make FastDot And FastPoint Do.
It's quite the speed up from older commands.
It's even faster with shorter ray lenghts.
It's not done but I'm experimenting.
First I need hieght values for scaled columns.
Then I need Colour values from colour map.
I'm going to get rid of fisheye distortion caused by spherical projection its a distance correction.
I haven't worked out the final projection but it's a start with many a read.
Any ideas how to make it faster so far? Or what is the best commnads (Fastest!) to use to draw scaled columns?
Obviously, The third loop so far will be different since that will be the final display.
but the question is can the first two loops be reduced to one! or get rid of the redundency of the loops?
It would be nice to know right from the start if there's a better approuch for faster rendering times.
Thanks
ScottieB
The fastDot/FastPoint commands are about a decade old now :)
yeah...I don't know why there's 2 loops doing the same thing, so one would be better, or why there's cos/sin computations insides the loops... so a more optimal version of the loop would be,
[pbcode]
For Rays = 0 To X_Screen_Res
ca#=Cos(Player_Angle + FOV_Angle#)
sa#=Sin(Player_Angle + FOV_Angle#)
For Lenght_Of_Ray = 0 To Maximum_Lenght_Of_Ray
X_Player_Eye = X_Player + ca# * Lenght_Of_Ray
Y_Player_Eye = Y_Player - sa# * Lenght_Of_Ray
Colour = FastPoint(X_Player_Eye,Y_Player_Eye)
Voxel_Height(Lenght_Of_Ray , Rays) = Colour
Next Lenght_Of_Ray
FOV_Angle# = FOV_Angle# - Increment_FOV_Angle#
Next Rays
[/pbcode]
If you move Cos / Sin out the inner loop, that's at least 4 instructions per pixel that dont need to be calculated.
You can get rid of the point and array read / writing completely.. It worth noting that CPU's don't like reading from large 2d arrays, so it can be more optimal to use tiles.
Anyway, for production code what most coders do is they unroll the inner loop calculations out to the simplest form possible. Normally a 4 or 8 to 1 ratio is most effective. So 4to1 means 1 loop for every 4 pixels..
[pbcode]
Size = 50000
Do
cls 0
frames++
t=timer()
// mock up brute force loop inter
For lp=0 to Size
x=x+speedX
y=y+speedY
next
tt1#+=timer()-t
print tt1#/frames
// mock up unrolled loop
t=timer()
// mock up unrolled loop
X1 = X+SpeedX1
X2 = X1+SpeedX1
X3 = X2+SpeedX1
X4 = X3+SpeedX1
Y1 = Y+SpeedX1
Y2 = Y1+SpeedX1
Y3 = Y2+SpeedX1
Y4 = Y3+SpeedX1
SpeedXBy4 = SpeedX*4
SpeedYBy4 = SpeedY*4
For lp=0 to (Size/4)-1
; pixel 1
x1=x1+speedXby4
y1=y1+speedYby4
; pixel 2
x2=x2+speedXby4
y2=y2+speedYby4
; pixel 3
x3=x3+speedXby4
y3=y3+speedYby4
; pixel 4
x4=x4+speedXby4
y4=y4+speedYby4
next
tt2#+=timer()-t
print tt2#/frames
sync
loop
[/pbcode]
I get the moveing of sin/cos correctly.
Not understanding the tiles thing though? I need to store information (arrays) for 3d-projection later. Did'nt know CPU's didn't like this as I thoought most programmers used theses while programming. But I still would like to understand what tiles are about? Sounds like a pixel average. still how's that going to be stored for later use?
Yes, I can get rid of the last loop since it's just for testing purposes and this will be replaced by the 3d-projection but...
Is there a way to make a loop that will do reading/writing from multiple maps? Or do I have to do each one separately? Like my above code I want height values then I want colour values each
from different maps but can this loop be reduced to one and still get both data from both maps?
I could probablyget rid of some arrays if I did'nt have to lock/unlock bufffers but I have to too use fastDot/fastpoint unless I can render elsewhere's as I read/write with them but that again
uses another image/screen that I have to write too. So How can I approach this where I read/writeing all over the place?
QuoteI get the moveing of sin/cos correctly.
Not understanding the tiles thing though? I need to store information (arrays) for 3d-projection later. Did'nt know CPU's didn't like this as I thoought most programmers used theses while programming. But I still would like to understand what tiles are about? Sounds like a pixel average. still how's that going to be stored for later use?
Reading from memory is slow, very slow.. So CPU's pull chunks from the memory in the various cache levels. When you read from memory it grabs more data that you request, as it assumes they'll be needed. This is fine when a routine is reading fields in a structurue for moving through memory in a linear fashion, but ray casting isn't linear. So the wider the source texture the more cache hits you get.
Quote
Is there a way to make a loop that will do reading/writing from multiple maps? Or do I have to do each one separately? Like my above code I want height values then I want colour values each
from different maps but can this loop be reduced to one and still get both data from both maps?
just compute the rays X/Y coord and then use that on both..
Quote
I could probablyget rid of some arrays if I did'nt have to lock/unlock bufffers but I have to too use fastDot/fastpoint unless I can render elsewhere's as I read/write with them but that again
uses another image/screen that I have to write too. So How can I approach this where I read/writeing all over the place?
??? I didn't follow any of that...
I'd would just use a bank to sort the texture/height maps, then compute offset to each pixel and read/write from the them..
[pbcode]
Width =2^9 ; 512 pixels
Height=Width
// compute the number of bytes useds in a single row of pixels
BytesPerRow = Width * 4 ; (32 bit colours are 4 bytes )
// make some mock up surfaces in banks
TextureIMageBank = NewBank(Height*BytesPerRow)
HeightMapIMageBank = NewBank(Height*BytesPerRow)
// --------------------------------------------------------
Do
// --------------------------------------------------------
cls $304070
CurrentDrawColour+= $1234
ca# =cos(Angle#)
sa# =sin(Angle#)
CameraX= mousex()
CameraY= mousey()
X=CameraX
Y=CameraY
lockbuffer
For Ray=0 to 100
// Compute next point
x=CameraX+(Ray*Ca#)
y=CameraY+(Ray*Sa#)
// wrap X / Y within legal space..
X= X and $1ff
Y= Y and $1ff
// compute position within the image bank array
// this is the offset from pixel 0,0 (top left)
Offset = (Y * BytesPerRow) + (X * 4)
// Read the from pretend Height Map
TerrainHeight = PeekBankInt(HeightMapImagebank, Offset)
// read from the pretend Image
TerrainRGB = PeekBankInt(TextureIMageBank, Offset)
// render a 32bit colour to the texture at this location
// just for something to look at
POkeBankInt TextureImageBank, Offset,CurrentDrawColour
next
unlockbuffer
// bump the angle
Angle#=wrapangle(angle#+2)
// --------------------------------------------------------
// Copy the the texture to screen row by row
// --------------------------------------------------------
lockbuffer
DestPtr = GetImagePtr(0)
DestModulo = GetImagePitch(0)
; get the pointer to the bank
SrcPtr =GetBankPtr(TextureImageBank)
; copy the rows of pixels from the bank
For ylp =0 to Height-1
; copy this row of pixels
CopyMemory SrcPtr,DestPtr, BytesPerRow
// Movec Src to the next row
SrcPtr +=BytesPerRow
// Move output to next row
DestPtr+=DestModulo
next
unlockbuffer
sync
loop
[/pbcode]
That's a great solution for multiple maps.
Though in your code rays so be Ray length and I just have to add rays afterward because it's a nested loop.
But I get the picture now use bank statements to reach many maps at same time with one pass.
Thanks for pointing that out.
Kewl!
So, am I getting this right poke my colors from fastpoints into banks at start up and read them with peeks? So, this is an initialization phase and then I can read them all as wish or can I copy images directly into banks first? i.e. copymemory image-bank in one big chunk i.e. size first?
Here's an uudate it's not finished by no means but now you can see what I'm trying to accomplish, You now can see some sort of render/3d projection though it still can be better and
speeded up useing even wave surfing and it's still not clipped I was just working on getting it so you can see what I'm shooting for.
Though they will be columns for points with various height not pixels and distances are not perfect due to spherical distortion cause by sin/cos rays but your starting to see the output.
Question though Kevin I don't want to compute the distance formaulas inside the main loop do I??? So can they be pre-comuted for further speed enhancements?
the process of loading a load an image to a bank is basically the reverse of the previous example does, which copies the bank to the screen. Swap the Src and Destinations and your copying the other way. Expect you wouldn't do it from the screen, but rather the loaded image.
O.K.
Now here's a question?
How do I draw fast lines? because voxels are goiing to be strips or columns and wave surfing is just this...
Ys Is my height of the initial strip at first height value then only heights higher will need to be drawn or continued above like say its 100 then anything
above 100 to come along down the ray that is higher than 100 like 150 then we continue up to 150 ect...
but...
I need to draw fast line or strips so how can I fill columns with a rgb colour fast in memory or image fast so then I can blast them to the screen????
Take a look at update of proggie.
You'll see what I mean.
The question is I guess really how to I further add more speed??? Speed it up more. See if you now can see anything that can.
I reduced distance formulas and Now have map wrap arround and better visuals. See haveing problem with angle wraparound though and ideas on that too?
Thanks a bunch for the help with this one.
I sortof look like a floodfill but strips or quick line drawing from point to point. That's the key point to point in column so a real fast line drawing with may heights so Y = 100 - 150 then 150 -200 ect... Or some kind of way to draw fast lines.
Oh, Got the clamping done now but still wondering about speed ups!!!!
Thanks
ScottieB
Looking good..
Drawing vertical/horizontal stip in memory boils down to a loop and where you have a pointer (the address of something in memory) the starting pixel and then you write a pixel (PokeInt), then add to the current pixel address.. For a left to right line, you'd be adding the size of 1 32bit pixel (4). For a line that's top to bottom, then between each pixels is the number of bytes per line. So if the target image is 800 pixels and is 32bit, then the bytes per row would be 800*4..
eg
PixelAddress = (Address in memory starting pixel)
For Xlp = X1 To X2-1
pokeInt PixelAddress,This_RGB_COLOUR
PixelAddress+=4 ; move to mext pixel
next
or.
PixelAddress = (Address in memory starting pixel)
For Xlp = X1 To X2-1
pokeInt PixelAddress,This_RGB_COLOUR
PixelAddress+=BytePerRow ; move to mext pixel on the row bellow the previous pixel
next
There's few other unneeded calcs in the inner most loop, like if rather than grabbing the R chan from the height and flipping it, you can convert the height map up front, so whenyou pull the height, it's in the correct format.
Ys = (Altitude - Player_Height) * Scaler / Distance# + (X_Screen_Res / 2)
The (X_Screen_Res / 2) should pre computed outside the inner loop.
Also, since the colour is only need when a strip is visible, it'd be better to grab that inside the vertical clip.
[pbcode]
If Ys > Max_Height
// Read colour of this point
TerrainRGB = PeekBankInt(TextureImageBank,Offset)
For Y = Max_Height To Ys
FastDot Rays,Y_Screen_Res - Y,TerrainRGB
Next Y
;lineC rays,Max_Height,rays,Ys,TerainRG
EndIf
[/pbcode]
The clipping can be down with clip range. Although You probably should a version Y_Screen_Res minus one, as the range clip is inclusive
[pbcode]
; If Ys < 0 Then Ys = 0
; If Ys > Y_Screen_Res Then Ys = Y_Screen_Res
Ys = ClipRange(ys,0,Y_Screen_Res)
[/pbcode]
Thanks again for the help I'll work on it.
Any Ideas how we can get bi-linearal filtering like you have in images or do we have to implement somthing?
And the big question! ...
How do we add grasss or trees efficiantly? 3D-Sprite Scaling? 3D data used for sprite scaling or is there a better way or faster way???
Also Clouds / Sky? any ideas? Not sure how to approach making the project bigger? Some kind of structure on how to expand would be great!!!!
Upon further reading the altitudes can be filtered and the textures can be filtered for better output looks.
Thanks!
ScottieB
To apply a bilinear filter you'd need 4 colours. You then interpolate the 4 colours..
(0) LEFT RGB - (1) RIGHT RGB
(2) LEFT RGB - (3) RIGHT RGB
For the vertical strips, you'd interpolte the R.G,Bs from the last colour to the next colour..
// compute difference between the R channels
DR#= RGBR(OLD_COLOUR) -RGBR(NEXT_COLOUR)
do the same for GREEN and BLUE channels
Then divide the Height difference into the colour differences
So you compute change in colour over time (time being pixels in this case)
RSTEP# = DR# / float( OLD_Y-NEW_Y)
then the inner loop is basically
[pbcode]
CurrentR#= RgbR(OLD_COLOUR)
CurrentG#= RgbG(OLD_COLOUR)
CurrentB#= RgbB(OLD_COLOUR)
For CurrentY = OLD_Y to (NEW_Y-1)
Dot Xpos,CurrentY, RGB(CurrentR#,CurrentG#,CurrentB# )
CurrentR#+= RSTEP#
CurrentG#+= GSTEP#
CurrentB#+= BSTEP#
next
[/pbcode]
That's about it.... Although the GouruadStripV commands would be faster than such a loop.
Sprites:
For sprites, you'd need to write a Z buffer. So when you plot the pixels in the sprites, you compare the pixels Z depth with the display depth and only write if the Z is lower. So there's a lot of extra memory access with a zbuffer. But you could interleate the 'screen an dzbuffer into one buffer. So when you read/write the CPU is pulling data close to each other.
You could do it without a zbuffer, by clipping the terrrain vertical spans to the vertical spans of the sprites. There's probably a few gotcha's in doing both, there always is..
making any progress ??