Dark Bit Factory & Gravity
PROGRAMMING => Freebasic => Topic started by: Rbz on September 12, 2006
-
I compiled a new tinyptc library using directdraw to replace the older one with a proper vertical screen sync enabled (in fullscreen mode) and I'm wondering if you can test it for me :)
The new library looks a bit big (295kb) but when you compile your program, everything should be OK again...
To install:
1 - Make a backup of your older files: libtinyptc.a and libtinyptc-win.a of this folder C:\FreeBasic\lib\win32
2 - From "libtinyptc.rar" extract and copy the new tinyptc library ( libtinyptc.a and libtinyptc-win.a) to this folder:
C:\FreeBasic\lib\win32
Everything should work like the older tinyptc, in windowed mode there's no correct vertical sync (so you will need a delta time system) but in fullscreen mode it should work fine, anyway it's a good idea to use a delta time system...
Have fun!
Ps: Added a great source code example for you to test ;)
-
Fab; just what I was after. I'll test this out for you as soon as pos dude.
-
Seems to be running brilliantly mate. I did spot it doing a brief pause once whilst running the scroller, but it didnt happen again.
Welldone Rbraz.
-
Thanks for testing it ... 8)
-
im finding it quite a bit slower than the previous one it probably runs at round half the speed.
also how did you get rid of the init and main subs.
-
He's using what was missing from the proper Tiny_PTC library stuff. Mainly the Direct Draw bits that were for the syncing, for some reason they were left out. This version doesnt use any of the OGL stuff that used similar subs / functions to pretend they were from the TinyPTC library. I think this is great. And am still testing.
One thing I have noticed Rbraz dude, is that I can no longer use keys in my program loops. All except the Escape key.
I you look at one of my source codes I sent you; you'll see the following key implementation below. This however no longer works with your new groovy update.
Dim Key As String
While Key<>Chr(27)
UpdateEffect()
If Key=Chr(9) Then 'Tab key
DoSomething()
End If
PTC_Update @ScreenBuffer(0)
Key=Inkey()
Wend
Cheers and great stuff,
Clyde.
-
I will give this a good testing tonight and post back my results :) Thanks Rbraz.
-
Hehe, nice to see the sine scroll as the example.
I have tested several programs with this and they all work beautifully! Thanks Rbraz :)
The other thing I noticed is that it generates even smaller exes than tinyptc!
-
I've tried this on 3 very different platforms now and none of them have fallen over.
Looks really stable!
-
I have just compiled into static library the C source code of tinyptc windows v.0.8 found here http://sourceforge.net/project/showfiles.php?group_id=5722
And that tinyptc only support "Escape" key , to use with FB someone have added a way to intercept keyboard in main code of tptc and that's why it is a little bit bigger (when compiled) than this one.
But you can check if a key was pressed in your code just using windows API command "GetAsyncKeyState", check out the code below:
option explicit
option static
'-------------------------------------
'Windowed
'-------------------------------------
#define PTC_WIN
'-------------------------------------
' Includes.
'-------------------------------------
#include "tinyptc.bi"
#include "windows.bi"
'Screen width x height
Const XRES = 640
Const YRES = 480
dim shared buffer(XRES*YRES) as integer
dim shared as integer x,y1,y2
dim shared as double angle
dim c as integer
c = &hff0000ff
If( ptc_open( "Tinyptc - Key Test", XRES, YRES ) = 0 ) Then
End -1
End if
while(1)
y1 = 80 + sin(angle)*20
angle += 0.05
for x=0 to 639
buffer(x+(y1*XRES)) = c
next
y2 = 400 + cos(angle)*20
for x=0 to 639
buffer(x+(y2*XRES)) = c
next
'Check for TAB key
if (GetAsyncKeyState(VK_TAB)) then
c = &hffff0000
else
c = &hff0000ff
end if
ptc_update(@buffer(0))
erase buffer
wend
Press TAB to change bar colors, take a look at winuser.bi for more virtual key codes.
Btw, you can define your own, for example:
#define VK_A 65 'Define key "VK_A" which the ASCII code is 65 (A)
-
Thanks matey.
-
Thanks matey.
no probs :)
Hehe, nice to see the sine scroll as the example.
The best example for sure!
-
No bugs have been found, how about sticky this topic ?
-
You can sticky it too ya know mate :)
Anyway, it's stuck!
-
Cool 8)
-
And how's about sending it to Victor. :D
I think he's Brazillian too.
-
Nah, it's not necessary, because the people who like to use tinyptc are all here :cheers:
-
I'm going to leave this topic here, but it needs a dupe in the showcase. Was going to add it earlier on but I wanted to leave this topic intact for feedback. :)
-
I just thought you'd get some credit for making tinyptc with vertical synching. If I were you, I would send it to the dude many would benefit. But it's your call.
Nice work too dude.
I have a DirectX problem that im trying to fix; which isnt due to the new update to tinyptc.
Cheers and nice one,
Clyde.
-
It's nice to have it here though Clyde don't you think? It's good to make tools like this only available to the members that support our place.
-
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 (http://www.gaffer.org/)
..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 :||
-
** 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!
-
Nice one mate :)
-
Sounds cool Rbraz dude not tried it out yet.
For those like me, what is an MMX?
Cheers,
Clyde.
-
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...
-
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.
-
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.
-
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.
-
When I do all the above, Rbraz dude I get the following errors: Undefined Reference to Ptc_Open, Ptc_Close, Ptc_Update mate.
-
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:
memcpy(dst,src,pixels*4);
And with MMX, you will see this ASM code:
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 ???
-
Nevermind, I'll revert back to the normal version.
Thanks.
Clyde.
-
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....
-
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.
-
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.
-
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.
''
'' 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
-
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 ;)
-
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 (http://dbfinteractive.com/index.php?topic=583.0)
-
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 :)
-
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
-
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 ;)
-
Thanks Rbraz!
So . . . it was me being dim . . . :)
Regards Drew
-
Rbraz my man, Im having big problems with using the keys with in programs
For example if I have transitions that are activated by the Escape key Or Tab, the transition code will be ignored and the program simply terminates.
Maybe there is a way to flush the keybuffer in one of those libraries, or can it be simply removed from the includes ( as Im using PTC_Close() after everything is done) ?
Btw, I am using the DDraw and MMX adaption to TinyPTC you made and not the ogl stuff.
Cheers and many thanks,
Clyde.
-
Ok, I'll compile another library without escape key later, but you will need to keep using "GetAsyncKeyState" api command since I don't know how to make it compatible with Freebasic inkey$ command.
That's ok for you ???
-
Ok dude, that'll be super and thank you. And please the direct Draw & mmx one. This'll be so cool :)
Cheers buddy,
Clyde.
-
Here's the special lib version for you Clyde, I'm using the old FB 0.15 , I guess you will need to change that "tinyptc.bi" included.
Good luck!
-
Cheers buddy much appreciated.
-
Just dropping by because I noticed a possible bug which occurred in Lithium's AntiMan (http://antiman.pbasichasnoballs.com/) and shockwave's invite for the 20 sec compo - I normally have FRAPS running in the background to monitor framerates of stuff and take vids, and when I run a program using this TinyPTC replacement (at least that's what I assume the culprit is), my primary monitor is totally black after the program exits and won't repaint until I drag some specific programs across it (I have a dual-monitor setup). Not sure if this is a FRAPS bug or a problem with this lib or both, but just wanted to let you know. If I close FRAPS first and then run the programs, they work fine, so I'd lean toward it being a problem with FRAPS, but then again, FRAPS seems to work fine with other programs. No big worries, just a heads up. (btw, FRAPS reports a nice steady 60 FPS :))
-
Thanks DrV :) Rbraz will find this feedback useful I am sure. He likes to do the best ob he can on Ptc :)
-
This version of TinyPTC was coded by Gaffer 6 or 7 years ago :o
It could fail with some new software that use directx, I had a similar problem using a software called "MediaKey", I need to uninstall it to run Tinyptc programs.