Tinypct question

[Shockwave]

Original post by Shockwave, taken from DBF Ezboard.

Tinypct question. Just a simple question about Tinypct, I've been playing with pixelwise stuff like starfields and plasmas, decided to see if I could combine it with some other stuff and fell flat.

It seems to me that tinypct simply provides a direct draw screen buffer. If this is the case, is there any way of using dd commands on it?

I am kind of hoping not and that everything will need to be poked into the buffer, this will give me a great excuse to develop a load of short routines to handle lines, sprites, polygons etc.

Probably if that's the case I'll release my sources here as I develop them.

In addition it may be a good time to start learning some gl and finally release some more demos.



¤´¨)
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´ (¸.·`¤... SHOCKWAVE / DBF...¤

VISIT DARK BIT FACTORY INTERACTIVE! (please!)

AlienEye0
*Administrator*

Posts: 172
(17/4/06 18:16)
Reply
   Re: Tinypct question. I think (there I go again) and I maybe wrong on this that once you link to dd through tinyptc you can make calls to any of the dd routines. I have looked at the stuff only since yesterday, so I might be waaaaaay off here. But if you look at the dd library you can see the routines - just like calling a function in basic or a standard .dll call I think.Someone let me know if I'm way off here as I'm interested too.


rbraz
CBM 128

Posts: 173
(17/4/06 19:43)
Reply
   Re: Tinypct question.

    Quote:..... is there any way of using dd commands on it?


    Quote:...link to dd through tinyptc you can make calls to any of the dd routines.


No, I'm sorry, Tinyptc have only pixel buffer to play with it.
You have only 3 commands:
1 - ptc_open
2 - ptc_update
3 - ptc_close

    Quote:I am kind of hoping not and that everything will need to be poked into the buffer, this will give me a great excuse to develop a load of short routines to handle lines, sprites, polygons etc.


Here's where the fun starts, we need to hard code all those stuff



Clyde Radcliffe
Fuzzy Wuzzy

Posts: 18249
(17/4/06 21:05)
Reply
   Re: Tinypct question. Ive had all sorts of problems myself with using TinyPTC, and have found that GFXLib the standard used graphics stuff that FB uses to be much better, its also alot better on FPS too.

I even used SDL to do a few things with, but its not that good. In my experience, as this maybe different for everyone, that it uses a different refresh rate, and gives me a borders at all sides of the screen. Asking questions on the official forums has resulted in not much cop, as many of them including the creator havent used many of the libs. Which i find a bit amusing.

There maybe some leaks and bug tweaking still left to do with the include binaries / libs for FB, as its still in beta form. They often state to visit the CVS Repositorty for updates to the libs etc. As what i find silly, is that they dont carry with new Freebasic updates.

rafryer
VIC 20

Posts: 11
(17/4/06 21:20)
Reply    tinyptc Basically all tiny_ptc does is copy (when ptc_update is called) data from an area of normal ram that you've set aside (Dimmed or allocated or whatever) to the page on the video card that's created when you called ptc_open.
In the ptc_test example program the @ in:

ptc_update @buffer(0)

means to copy starting from the memory address in normal ram of buffer element 0.

The area of memory you dim or allocate must be at least the size of a 32 bit instance of the screen you've opened (width*height*4 bytes) and you can make as many pages as memory'll allow. Some older gfx cards don't support 32 bit gfx and tinyptc will take the 32 bit data from your page and convert it appropriately for the display if that's the case so there's no need to make any changes to your code.

Fryer

5H0CKW4VE
*Administrator*

Posts: 8005
(17/4/06 23:29)
Reply
ezSupporter

   Re: tinyptc Thanks very much, that confirms what I thought.
Time to code a load of short stuff to do the mundane things.

Another advantage has got to be the smaller exe size too Clyde, tinyPCT exes are a good deal smaller. Speed wise it's faster than B+ so there's plenty of scope for textured vectors and alpha'd sprites etc I would think. That's just going from my tests where it can render a screen full of unoptimised plasma at full frame rate in 640 X 480.

B+ would struggle a little to do that... And the exe would be a few 100 k bigger too.



¤´¨)
¸.·´¸.·*´¨) ¸.·*¨)
(¸.·´ (¸.·`¤... SHOCKWAVE / DBF...¤

VISIT DARK BIT FACTORY INTERACTIVE! (please!)

[Blitz Amateur]

Ive not used GFXLib personally, but I did do a quick tinyPTC screen fade test, and it's really fast on this old laptop. At 320x240 fading from white to black, I get 118 FPS

[Shockwave]

The speed is definately up there with the best.
I reckon that if a coder wanted to spend some time and make a good set of routines to do the boring stuff like draw polygons, plot dots, draw lines etc. that there is no reason why it couldn't be as easy to use as Blitz.
It just takes a little work in the beginning.

I have also stayed away from GFXlib, mainly because I got such a glitchy refresh rate when I tried it out.

[Clyde]

I've found the reverse on certain effects dude. I prefer GFX Lib for it's simplisity, especially from converting over from Blitz with. But it bares slightly bigger executables then tiny ptc. Which Im presuming is why peeps are opting for MR Tiny.

Perhaps then, there's a call for making custom includes, for gfx lib. But saying that, it's funny how gfxlib is bigger seeming as you dont need to use it as an binary include, as it's the default gfx functions.

At the moment im 50 - 50 to liking Tiny / GFXLib.

I for one can't wait until FreeBASIC comes into full release. If it where on the market, I'd snap it up in a jiffy. It's even cooler its free for all. And If Victor and his cronies are lurking, congrats on a fine language.

Cheers,
Clyde.