New tinyptc library

[Rbz]

I just thought you'd get some credit for making tinyptc with vertical synching...

No please, it's not necessary any credit for me, all credits goes to Gaffer

..I would send it to the dude many would benefit...

When someone who likes tinyptc and FB search for vertical sync enabled, they will find DBF/GVY forum 

[Rbz]

** Added mmx support ***

New files:
libmmx.a
libtinyptc.a
libtinyptc-win.a

Copy these files to your Freebasic installation, example: C:\FreeBasic\lib\win32\

And the new tinyptc.bi to the this folder: C:\FreeBasic\inc\



Enjoy!

[Shockwave]

Nice one mate

[Clyde]

Sounds cool Rbraz dude not tried it out yet.
For those like me, what is an MMX?

Cheers,
Clyde.

[Rbz]

http://en.wikipedia.org/wiki/MMX

Sorry, I can't explain it better than Wikipedia 


Anyway, Gaffer had added it to optimize the blitter routines of tinyptc, with MMX support it should be a little bit faster...

[Shockwave]

And as the old tesco advert goes... Every little helps!
Actually I'll test this now. I have an intro ready to go and without the MMX it is;

128 - 144 fps.

And now gentlemen I will install the new lib files....

Aaaannnnd.

128 - 144 fps, however there are less of the 128 fps so I guess it's running slightly quicker.

[Clyde]

So basically it's to make it work a tad better inconjuction with Pentium processors.
Cool, will try this out when I get home.

Thanks,
Clyde.

[Shockwave]

I think MMX stuff only really makes a difference with integer operations though (I might be wrong) and since the intro uses delta timing and lots of floats it may be having less of an effect. I perhaps should have tested a few other things before I installed the new bits.

[Clyde]

When I do all the above, Rbraz dude I get the following errors: Undefined Reference to Ptc_Open, Ptc_Close, Ptc_Update mate.

[Rbz]

I think MMX stuff only really makes a difference with integer operations though (I might be wrong) and since the intro uses delta timing and lots of floats it may be having less of an effect. I perhaps should have tested a few other things before I installed the new bits.

Looking at tinyptc source, for example, for copying a buffer to another, without MMX you have this C code:

Code Select Expand

memcpy(dst,src,pixels*4);

And with MMX, you will see this ASM code:

Code Select Expand

align 16

_mmx_memcpy:

Ã,  Ã,  push ebp
Ã,  Ã,  mov ebp,esp

Ã,  Ã,  pushad

Ã,  Ã,  mov edi,[ebp+8]Ã,  Ã,  Ã,  Ã, ; destination
Ã,  Ã,  mov esi,[ebp+12]Ã,  Ã,  Ã,  ; source
Ã,  Ã,  mov ecx,[ebp+16]Ã,  Ã,  Ã,  ; bytes

Ã,  Ã,  mov eax,ecx
Ã,  Ã,  shr ecx,6
Ã,  Ã,  mov ebx,ecx
Ã,  Ã,  shl ebx,6
Ã,  Ã,  sub eax,ebx

align 16
             
    .loop

        movq mm0,[esi]
        movq mm1,[esi+8]
        movq mm2,[esi+16]
        movq mm3,[esi+24]
        movq mm4,[esi+32]
        movq mm5,[esi+40]
        movq mm6,[esi+48]
        movq mm7,[esi+56]
        movq [edi],mm0
        movq [edi+8],mm1
        movq [edi+16],mm2
        movq [edi+24],mm3
        movq [edi+32],mm4
        movq [edi+40],mm5
        movq [edi+48],mm6
        movq [edi+56],mm7
        add esi,8*8
        add edi,8*8
        dec ecx
        jnz .loop

    mov ecx,eax
    rep movsb

    emms

    popad
   
    pop ebp
    ret


Well, I think it should be faster, because they are coded in ASM, and Gaffer is a good coder...

When I do all the above, Rbraz dude I get the following errors: Undefined Reference to Ptc_Open, Ptc_Close, Ptc_Update mate.

Sorry dude, I don't know how to help you if you really did all procedures aboveÃ,  

[Clyde]

Nevermind, I'll revert back to the normal version.

Thanks.
Clyde.

[MrP]

MMX is basically an simd extension for the pentium processor. The simd stands for single instruction multiple data. The MMX registers are 64 bits long rather than the standard 32 bit registers of the processor. If you wanted to blit something really fast (and providing your screen color depth was 32 bits) you could blit in 64 bits rather than 32, in effect you could read and then write two pixels at a time to the screen. However where MMX really comes into its own is the ability to do more than one thing at once. Imagine if you took one 32bit pixel from the screen and you needed to do a calculation on the red, green and blue pixels. Using code without MMX you would have to extract the rgb values into seperate variables. do whatever you need to do them, then reconstruct those back into a single 32 bit integer which you can put back to screen. When using MMX you can load an MMX register with a 32 bit integer contaning your rgb values (Generally the integer would look like 00RRGGBB). Then pass one add or sub instruction to that register and it will operate on all color components at once. For example if you wanted to add 10 to the rgb values of a pixel on screen just load that pixel into an mmx register add 10 to that register then write that register back to screen. The mmx add instruction adds 10 to all the bytes in the register, so in theory your adding 10 to the individual rgb values of the pixel color with one instruction. There is even an instrucion which will pad the values at 255 (or at 0 if your subtracting) so there is no need to check whether your rgb values are within limit or not. Because however the registers are 64 bits long you could effectively load two pixels into a register do that add or sub on them then write them both back to screen. Two pixel individual rgb color calculations with one instruction, thats the real power of MMX. If however you need to do a multiply or divide on the rgb values you have to unpack the initial 32 bits into the full 64 bits of the register then do the math on them, then repack them into 32bits and write them back to screen. There is however a problem with MMX if your doing a lot of calculations using the floating point registers of the processor. You do not get extra 64 bit registers just for MMX stuff, instead the mmx registers alias themselves onto the lower 64 bits of the eight 80 bit floating point registers so if your doing mmx stuff along with floating point stuff you have to issue a command at the end of your mmx instructions to restore the floating point registers back to what they were before you started, and unfortunately that instruction takes a fair few clock cycles so if its not used right can have a big impact on your frame rate. Hope this helps to exlpain a bit more of what the MMX extensions are capable of, and apologies if this is a little off topic....

[Shockwave]

Mr.P there's no need to apologise, it's all relevant.

Clyde, it's only replacing 4 files so it should work for you.

Rbraz, well let's put it this way, the program hasn't slowed down I'm happy to stick with this version.

There were a couple of questions that occured to me. I noticed that you run your version of ptc in a scalable window, how much hassle would it be to be able to specify a requester, let's say at the start of the program to choose;

Scalable Window
Fixed Size Window
Full Screen
V/Sync On/Off

And would it increase the size of the exe dramatically?

Another thing that I am interested in is reading the mouse. This was definately possible with the version that Jim put up because I saw the mouse pointer, do I need to include the fbgfxlib to be able to read the mouse or can it be done through GL?

Thanks and sorry to be a pain in the ass.

[Clyde]

Everytime I run with the new updates files, it tells me the following:

Compiler output:
C:\Rbraz\tinyptc_stuff\test.o:fake:(.text+0x3f): undefined reference to `ptc_open'
C:\Rbraz\tinyptc_stuff\test.o:fake:(.text+0x15e): undefined reference to `ptc_update'

Results:
Compilation failed

Im runniing the latest version of Freebasic. And have tried this numerous times with various TinyPTC programs.

[Clyde]

This corrects it and allows it to work with the latest version of Freebasic.
For some reason it doesn't like how you told it to include various stuff, with $inclib:"whatever"
Which you'll see by looking at the code below.

Code Select Expand


''
'' TinyPTC by Gaffer
'' www.gaffer.org/tinyptc
''

''
'' add the -d PTC_WIN option to fbc's command-line to use the windowed version
''
#if defined(PTC_WIN) and not defined(__FB_DOS__)
# inclib "mmx"
# inclib "tinyptc-win"
#else
# inclib "mmx"
# inclib "tinyptc"
#endif

'' tinyptc api
declare function ptc_open cdecl alias "ptc_open" (byval title as zstring ptr, _
byval width as integer, _
byval height as integer ) as integer

declare function ptc_update cdecl alias "ptc_update" (byval buffer as integer ptr) as integer

declare function ptc_close cdecl alias "ptc_close" () as integer

#ifdef __FB_WIN32__
# inclib "ddraw"
# inclib "user32"
# inclib "gdi32"
#elseif defined(__FB_LINUX__)
# inclib "X11"
# libpath "/usr/X11R6/lib"
#elseif defined(__FB_DOS__)
'''
#else
#error Platform not supported!
#endif


[Rbz]

Nice work Clyde,  I'm still using Freebasic 0.15  , they changed that stuff with inclib in the new version...

There were a couple of questions that occured to me. I noticed that you run your version of ptc in a scalable window, how much hassle would it be to be able to specify a requester, let's say at the start of the program to choose;

Scalable Window
Fixed Size Window
Full Screen
V/Sync On/Off

And would it increase the size of the exe dramatically?

Another thing that I am interested in is reading the mouse. This was definately possible with the version that Jim put up because I saw the mouse pointer, do I need to include the fbgfxlib to be able to read the mouse or can it be done through GL?

Yeah dude, all those features can be done without any big increase of the exe (few kb's)  and without fbgfxlib, I'm just not sure if I could change  the original source of tinyptc (author rights etc)...

So, I'm thinking in keep the development of tinyogl by Jim, the framework for it, with all those features, it's not that hard to implement.

Just need some free time 

[Clyde]

Another thing that I am interested in is reading the mouse. This was definately possible with the version that Jim put up because I saw the mouse pointer, do I need to include the fbgfxlib to be able to read the mouse or can it be done through GL?

Dude as your including windows, all you have to do is use the mouse like in Jim's posts at this Mouse Pointer

[Shockwave]

Thanks Clyde, and thanks to you too Rbraz I'll look forward to seeing those features in a future release when you get the time

[DrewPee]

Excuse me for being dim - does this new tinyptc library work with full screen? as the old one? cant seem to get it to work? and should we use this version or the one that Jim is doing?
Im a little confused?

Drew

[Rbz]

Excuse me for being dim - does this new tinyptc library work with full screen? as the old one? cant seem to get it to work?

It should work like the old FB tinyptc, just remove #define PTC_WIN from your code, if this isn't working can you post your code ?

and should we use this version or the one that Jim is doing?

It's a matter of taste, this new tinyptc use directdraw and vsinc is enabled (you can't change it).

But for Jim's library it use OpenGL and you can change vsinc On-Off, you can select Windowed/Fullscreen mode in one file, you can check for mouse position and button state.

Well, what can I say... Jim tinyogl is alot better