PureBasic Forums - English

Restored from previous forum. Originally posted by THCM.

Hi I would like to have direct memory access to the screen after using OpenScreen. Usable parameters are: Pointer to the Screen, Pitch for advancing one line to another, Pixel Format (depth and rgb structure). I need this stuff for my Mandelbrot zoomer! I tried Darkbasic Pro (it has direct access to the screen), but it's a lot slower than Purebasic!

Thanx!

PS. I don't want to use Windows-Api!

The Human Code Machine / Masters' Design Group

Restored from previous forum. Originally posted by fred.

Why not using Plot(), as it a direct memory access when used with ScreenOutput()..

Fred - AlphaSND

Restored from previous forum. Originally posted by THCM.

Hi Fred!

The plot() command uses x and y positons to calculate the exact memory adress of the pixel. If i have the start adress of the framebuffer i can draw my frame from top left to down right with only a few additions to the starting point. Adding $02 or $04 to the last framepointer adress to get a pixel to the right is a !lot! faster than calculating each pixel.

Just imagine you have a screen with 640x480 pixel (small one). You have to calculate 307.200 pixel positions. Try this to do 30 times a second!!! (Over 9.000.000 calcs!) Let's say calculating the correct position takes about 20 cycles, my add command only takes 1-2 cycles! This is about 20 times faster than your suggestion of drawing!

I'm talking here about full screen manipulation like Mandelzoom, Fire-Effect, Doom-Like 3D engine etc. where you have to draw the whole screen.

Perhaps you say: Use OpenGL or something else, but i like to test and code some oldskool stuff.

I personally have a copy of Blitzbasic 3D and Darkbasic Pro. With these Basic-Compilers you can do lots of fancy stuff, but they are veeerrryyyy slow!!

In the past i used to code 6502 and 680X0 assembler (Games and Demos for CBM 64 and Amiga (Masters' Design Group). I even did some 80X86 stuff (protected mode dos). And i think that Purebasic is a good compromise to not learning C or C++.

Please rethink my request! I bought Purebasic for the above reasons, and even would spend a few more bucks, if you implement such features! It shouldn't be too hard to implement!

Thanx in advance,

Uwe Anfang

The Human Code Machine / Masters' Design Group

Restored from previous forum. Originally posted by fred.

You're totally right. I will add the needed commands to access the screen buffer. Here is my suggestion:

ScreenPitch() : returns the number bytes per line
ScreenBuffer(): returns the start of the actual screen buffer
SpriteBuffer(): the same, for sprite -> direct drawing on sprite possible.

If you have other suggestion, just tell me !

Fred - AlphaSND

Restored from previous forum. Originally posted by THCM.

Hi Fred!

Great news indeed!

ScreenPitch(): should be the number of bytes to advance one line!
If you only have the number of bytes per line, it's not sure that you get to beginning of the next line! It depends on the GFX-Card or Driver! (Only think about 24 Bit Display!)

ScreenBuffer(): Correct!
SpriteBuffer(): Cool!

What about:
ScreenPixelFormat(): Should return the used pixelformat where is:
SpritePixelFormat():

0 - 32 Bit ARGB
1 - 32 Bit ABGR
2 - 24 Bit RGB
3 - 24 Bit GBR
4 - 16 Bit RRRRRGGGGGGBBBBB
5 - 15 Bit XRRRRRGGGGGBBBBB

etc.

With this information it's easier to draw to the screen without hassle!

What's about locking the framebuffer before writing to it? I've seen this option in Blitz and DarkbasicPro. Do we need this option if another thread tries to use DX functions with our open screen?

I found another reason for implementing this stuff: Try to write a library for purebasic in assembler which tries to access the frambuffer without info about it?

Thanx in advance!

The Human Code Machine / Masters' Design Group

Restored from previous forum. Originally posted by fred.

In fact, I will implement them in the 2DDrawing library. The buffer need to be locked and it's done with a StartDrawing(). This will allow to do direct drawing on legal bitmap, window etc..

Commands will be:

DrawingBuffer()
DrawingBufferPitch()
DrawingBufferFormat()

Is it ok ?

Fred - AlphaSND

Restored from previous forum. Originally posted by THCM.

Ok! Will the feature be available in V3.40 ???

Yours, Uwe!

The Human Code Machine / Masters' Design Group

Restored from previous forum. Originally posted by fred.

It's done. Just send me a mail to get the new lib and do some beta test . Will be for v3.40.

Fred - AlphaSND

Restored from previous forum. Originally posted by PB.

> It's done. Just send me a mail to get the new lib and do some beta test . Will be for v3.40.

This is exactly why I love PureBasic!


PB - Registered PureBasic Coder

Restored from previous forum. Originally posted by fred.



Fred - AlphaSND

Restored from previous forum. Originally posted by Franco.

Fred, live long and prosper...

Have a nice day...
Franco

Sometimes you have to go a lonely way to accomplish genius things.

Restored from previous forum. Originally posted by WolfgangS.

>Fred, live long and prosper...


"Cheers" klingklingklingklingklingklingklingkling glugluglugluglugluglu !

Restored from previous forum. Originally posted by PB.

> would spend a few more bucks, if you implement such features!

I've always considered this idea too. That is, someone (Fred/Danilo)
could offer to write custom libraries for people, for a small price.
I'd definitely pay if the price was kept low.


PB - Registered PureBasic Coder

Restored from previous forum. Originally posted by Berikco.

Originally posted by PB

> It's done. Just send me a mail to get the new lib and do some beta test . Will be for v3.40.

This is exactly why I love PureBasic!

Me to, also the date functions where quicly included for 3.40
Cant wayt for the release of 3.40


Regards,

Berikco

http://www.benny.zeb.be

Restored from previous forum. Originally posted by blueb.

Berikco,
Me too!

Seriously, after I purchased PureBasic 2.30 last year, I
thought..."Kind'a cool, but needs some work"

But now, it is turning out to be an exceptional tool. Fred's
doing an amazing job of advancing PureBasic.

Thank you very much, it is appreciated!

Regards,
--blueb