TTD graphics lib Progress

[TinDragon]

Hi everyone,

Since I seem to have a bit of the coding bug again I took a look at this freebasic some of you are using, since it seems a fairly easy language to grasp I thought I would have a bash at making use of tinyptc under it to develop a prototype for a C/C++ based lib , what I will most likely do is get a basic set of "blitz" like functions working in FB first then work on the C version. So I started on this about 1:30pm and now at 2:55pm I am writing this post with the first super basic version of the lib up and running. So far it doesn't do much but it's a start, I attach a little exe of the first working program and below is the code for the test, minus the lib include but I think everyone here could make what I have so far judging by some of the code and demos you have done and I believe one of DBF was working on something like this already

Code: [Select]

#include "ttdblitzlib.bi"
'-------------------------------------------------------------------
' Test of Lib
'-------------------------------------------------------------------
TTDGraphics(640,480,"TTD Test App")
    do 
        TTDCls(0,0,0)
        for Y=0 to YRES-1
            for X=0 to XRES-1
                R=RND*255
                G=RND*255
                B=RND*255
                TTDPlot(X,Y,R,G,B)
            next
        next
        TTDFlip()
    loop until inkey$<>""
    TTDEndGraphics()
end
'-------------------------------------------------------------------
' End Test of Lib
'-------------------------------------------------------------------


[Blitz Amateur]

Looks decent so far. I posted up a lib on here that has a super fast way of clearing the buffer for redrawing, and a fast pixel plotting system. Might want to take a look at it 

http://dbfinteractive.com/index.php?topic=81.0

[zawran]

Argh, my eyes, my eyes, hehe.  Great that you have been bitten by the code bug   I haven't tried the FreeBasic, but I am keeping an eye on all the interesting stuff people are making with it, and it seems like a capable language. Looking forward to see more cool stuff from everyone.

[TinDragon]

Well Zawran, I did say it was a quick test LOL

BA, just downloaded the code from that link and I see your doing this

Code: [Select]

Sub ClsSurf()
   
    clear *buffer, 0, CLEARCOUNT
   
End Sub
To clear the screen buffer, now I assume that *buffer is used to referance the ptr to the buffer, and I am assuming the clear command clears the memory area to 0 for CLEARCOUNT number of bytes ??   If so then I think you could store in your code a CLSCOLOR like blitz does and instead of clearing the buffer to 0 clear it to a given color. Note I am only guessing as to what your codes doing as I haven't looked in the FB help on those commands yet

The way I have it set up for the cls is like this

Code: [Select]

'-------------------------------------------------------------------
' NAME : TTDCls()
' PURPOSE : This function clears the buffer to RGB passed
' INPUTS : Red, Green,Blue values range 0-255.
' RETURNS : nothing.
'-------------------------------------------------------------------
Sub TTDCls(ByVal Red as integer=0,ByVal Green as integer=0,ByVal Blue as integer=0)
    Dim ClsColor as integer
    ClsColor= ( Red shl 16 ) + ( Green shl 8 ) + Blue
    For y=0 to YRES-1
        For x=0 to XRES-1
            Backbuffer[(y*XRES+x)] = ClsColor
        next
    next
End Sub
But as you can see it's not going to be very fast, but it gives me complete color control. If we can combine the two ideas we will have a fast and color controlable cls command. Hmm better have a look at this clear command 

[Blitz Amateur]

Yes, the way I did it, you can "clear" the memory with any value at all. So you could very easily reproduce a BB ClsColor with a very high speed.

EDIT: I went and looked at the FB command reference, and it only allows you to clear an array with a value between 0 and 255

[relsoft]

Cool!!!!

[zawran]

Not sure if there is such a thing as memcopy, but if there is, you could allocate some memory same size as the screen. Fill that with the clscolor, and then do a memcopy from that to the screenbuffer. Could be a faster way of clearing the screenbuffer.

[TinDragon]

Hmm, having looked at this clear command it does it by bytes, now a 32bit integer is 4 bytes, so you cant just do a clear with an integer color instead of the 0 cos it wont work as expected since it expects an 8bit number. So I dont think there's an easier way to clear the screen to a color unless there's a way to make the command step in 4 byte steps ?

[EDIT]
LoL beaten by BA. Zawrans Idea would work if the background were a set color or only changed color at odd times meaning one quick recreate of the memeory area, but my method as it stands means the cls color can be changed per frame if needed. So while it might not be the fastest it is the most flexible at the moment. Sure someone can find a faster way

[relsoft]

Not sure if there is such a thing as memcopy, but if there is, you could allocate some memory same size as the screen. Fill that with the clscolor, and then do a memcopy from that to the screenbuffer. Could be a faster way of clearing the screenbuffer.

Clear uses memcopy. Â Or you could do a memcopy by including wincrt and call memcopy.:*)

[TinDragon]

Well I got Line drawing in, So I am one step further along. Wish I could display my fps to see how fast this stuff is actually going.
By the look of it much faster than doing pixelwise stuff under b2d and possibly b+ and locked pixels, so thats a plus for FB

[Blitz Amateur]

for FPS, there is a timer var named "timer", and if you take the difference between that at the start of a loop, and then end, and do

Code: [Select]

print "FPS: "; 1.0/diffThat should help you out

[zawran]

Next step is probably doing a sprite function which can blit images to the buffer, which also could be used for at bitmap font. Seems like you are speeding along quite nicely.

[Stonemonkey]

For clearing a 32 bit screenbuffer, you could try something like this:

Code: [Select]

sub memset_dword(byval addr as any ptr, byval fill_with as integer, byval num_ints as integer)
 Â  Â asm
 Â  Â  Â  Â mov eax, [fill_with]
 Â  Â  Â  Â mov ecx, [num_ints]
 Â  Â  Â  Â mov edi, [addr]
 Â  Â  Â  Â cld
 Â  Â  Â  Â rep stosd
 Â  Â end asm
end sub

should be pretty fast, addr=start address of screen buffer, fill_with=colour to fill buffer with, num_ints=width*height of screen.

[TinDragon]

Wow, asm code. Now I am scared 

Haven't tried it yet but thanks for the subroutine, sure others will find it usefull as well.

BA, sure print wont work on a TinyPTC buffer

[Stonemonkey]

brief explaination for anyone interested:

the REP STOSD instruction does:

moves the value in the EAX register to the address (EDI)
modifies EDI, in this case adds 4Â  (4 bytes in a dword)
decrements value in ECX
repeats until ECX=0

I've seen this being used for filling the scanlines for triangles too, only does solid filled tris (well could have different colours for each scanline) but probably extremely fast.

[Shockwave]

Good luck with the lib Tindragon, I'm sure that you'll find FB miles faster than Blitz, I'm still being amazed by it myself.

Stonemonkey, thatnks for posting the fast ASM, is that faster than using option dynamic and re-dimming the array to clear it?

[Stonemonkey]

I'm not sure about the process of redimming but that must involve clearing the memory somehow and it possibly has to deallocate/re-allocate memory too so i'd imagine it's as fast if not faster and also lets you choose a value to fill with.

[Shockwave]

Thanks for that. It will make a big difference to my polygon command at least. I'll test it on the screen clearence.

[Stonemonkey]

You going to try it on solid tris? let me know how it goes as i've never got round to trying it myself.

[Shockwave]

Yes I'll use it on solid triangles, I'll post the source when I'm done.