Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - backspace

Pages: 1 [2] 3 4
16
GLBasic - en / What is MULTISAMPLE?
« on: 2013-Jan-19 »
In the Project > Options dialog: What does MULTISAMPLE do? 

17
GLBasic - en / Re: Android Media folder - How?
« on: 2013-Jan-18 »
Thanks Kitty

18
GLBasic - en / Android Media folder - How?
« on: 2013-Jan-15 »
Hi, me again, but this time with an Android question.
I'm getting closer to my GLBasic goals, and decided to detour to test on Android. I have all the SDK's and Java stuff set up.
The problem however is I can get the APK copied, installed and run the app on my device, but I do not have the media files or folder available to the app. I checked inside the .apk and it's also not in there. The app runs great on my device, except it has no media files to support it.
Do I have to do something manually in order to get the media folder and files onto the device?

19
2D-snippets / The start of a Painting program
« on: 2013-Jan-13 »
After a lot of fun and headaches with the MEM* commands, some of which still need to be resolved, I finally got the basic ideas for a painting program to work.
There's still a lot of work to do, but this should serve as a sample of having some simple "painting" fun

Left mouse button to paint
Right mouse button to reset

Images uses in this sample are attached.

Code: (glbasic) [Select]
// --------------------------------- //
// Project: mem-paint-test
// --------------------------------- //


SETCURRENTDIR("Media")


LOCAL PX1%[], PX2%[]
LOCAL x,y,r,c,i,mx,my,mbl,mbr,rr,cc
LOCAL cr,cg,cb,ca
LOCAL argb%


CREATESCREEN 1,1,640,480
CREATESCREEN 2,2,40,40
CREATESCREEN 3,3,640,480

LOADSPRITE "catndog1.png",1
LOADSPRITE "ball.png",2


WHILE TRUE

//get mouse state
MOUSESTATE mx,my,mbl,mbr

//reset image - should build load safety timer here.. but its a test anyway.
IF mbr = 1 THEN LOADSPRITE "catndog1.png",1


//check that the mouse right and bottom are on the screen
//.....else the arrays fall over

IF mx+39 < 640 AND my+39 < 480
//get the background
SPRITE2MEM (PX1[],1)

//get paintbrush 
SPRITE2MEM (PX2[],2)

//paste brush onto background
IF mbl = 1
rr = -1
FOR r = my TO my + 39   //for each row
rr = rr + 1
cc = -1
FOR c = mx TO mx + 39  //for each column
cc = cc + 1

argb = PX2[cc+rr*40]
cr = bAND(argb, 0xff)
cg = bAND(ASR(argb,8), 0xff)
cb = bAND(ASR(argb,16), 0xff)
ca = bAND(ASR(argb,24), 0xff)

IF ca <> 0
PX1[c+r*640] = argb
ENDIF

NEXT
NEXT
MEM2SPRITE (PX1[],1,640,480)

ENDIF
ENDIF     //mouse in screen

//START DRAWING from here
USESCREEN -1

//dump background
DRAWSPRITE 1,0,0


//display paintbrush
DRAWSPRITE 2,mx,my

PRINT "Right Mouse button to reset", 5,450
SHOWSCREEN
WEND

[attachment deleted by admin]

20
Luckily I don't give up easily. I've found a work-around, but this still does not solve the MEM2SPRITE "lockout" problem.

What I've done is create a new screen and sprite, and then draw my image and other stuff on that, then use the new sprite to display the results.

I'm a little concerned about the overhead of creating a new screen in a a game loop. since the paintbrush will need to continuously update the image via a new screen, 60 or more times a second. If it's a pointer to a newly created class instance, then that's ok, since that's what c+ is made to do anyway, but this does raise the possibility of memory leaks. (No offense to the programmers, it's one of the things about c++)

Here's the workaround. It does exactly what I need, but leaves me with performance and memory leak concerns.

Code: (glbasic) [Select]
// --------------------------------- //
// Project: sprite2mem-tes-13
// --------------------------------- //

SETCURRENTDIR("Media")

LOCAL PX1%[]
LOCAL argb%
LOCAL r,y

CREATESCREEN 1,1,320,240
CREATESCREEN 2,2,320,240
CREATESCREEN 3,3,50,50

USESCREEN 3
DRAWRECT 0,0,49,49,RGB(255,0,0)
USESCREEN -1

LOADSPRITE "dogncat1.png",1

SPRITE2MEM(PX1[],1)
MEM2SPRITE(PX1[], 2, 320, 240)   

// Create a new screen and sprite to use as an intemediary step to publish

CREATESCREEN 4,4,320,240
USESCREEN 4
DRAWSPRITE 2,0,0

DRAWSPRITE 3,200,100
PRINT "HI",5,5

USESCREEN -1
DRAWSPRITE 4,0,0

SHOWSCREEN
MOUSEWAIT


21
Oh my. Just when I thought I had everything sorted out, I ran into another snag.
This has all got to do with my MEM2SPRITE paint-thing, so I am continuing the new question here.

This time it looks as if the MEM2SPRITE is actually the cause of all my problems.
I am able to get a sprites onto  PixelArray[]s with SPRITE2MEM. This works perfectly.
I am able to manipulate the array data against another with all sorts of 'magic" using INLINE with no problems
I can convert the PixelArray[]s back to sprites with MEM2SPRITE, with a big smile.

BUT.. here comes the issue:
If I drawsprite the image after a MEM2SPRITE, I see all my work on the image.
If I print, drawline, drawsprite, or any of the other commands to the "screen" that holds the image (after a MEM2SPRITE)... Nothing happens
If I remove the MEM2SPRITE command, then the other commands all draw to that "screen" without any problems.

So it seems as of the MEM2SPRITE somehow "locks up" the screen and image, and wont accept anything else done on it.
Here's a little test program to illustrate my point.

On first run you can see the image, but not the PRINT "hello" and another drawn image drawn onto the "memsprite"'s image screen
If you comment out the MEM2SPRITE, then you can see that all the other stuff actually works ok.

Why this is important, is that I want to be able to sometime add some text to the image, or maybe even draw some lines on them, which can't really be done with MEM buffers.

Code: (glbasic) [Select]
// --------------------------------- //
// Project: sprite2mem-test-12
// --------------------------------- //

SETCURRENTDIR("Media")

LOCAL PX1%[]
LOCAL argb%

CREATESCREEN 1,1,320,240
CREATESCREEN 2,2,320,240
CREATESCREEN 3,3,50,50

USESCREEN 3
DRAWRECT 0,0,49,49,RGB(50,100,150)
USESCREEN -1

LOADSPRITE "dogncat1.png",1

SPRITE2MEM(PX1[],1)
MEM2SPRITE(PX1[], 2, 320, 240)   // <----------comment out this line and the rest works fine

USESCREEN 2
DRAWSPRITE 3,200,100
PRINT "HI",5,5
USESCREEN -1

DRAWSPRITE 2,0,0

SHOWSCREEN
MOUSEWAIT

Edit: I attached the image I used for the test. I kept it small for test purposes.


[attachment deleted by admin]

22
Hi Kitty,

Thanks for the reply. Yes that was a poor post I my part. I just dumped the code without an explanation. Sorry about that; frustration sometimes does get the upperhand and mess up the mind.

The problem was that I could not see any results from OR-ing the the two buffers together. The resulting buffer was "empty" for some unknown reason, and would not update anything onto the "screen".

I have however addressed the problem by passing the DGInt arrays to INLINE functions and using c to manipulate the byte data. All my pixel-magic algorithms are from c libraries anyway, so I can just INLINE the ones that I use. So I SPRITE2MEM in, do the INLINE stuff and MEM2SPRITE back again. This has solved all previous problems that I had.





23
Hi again,

This time it's my turn to ask a MEM2* question, but more to ask if anyone can see what I am wrong in my code.
This is my first attempt at using the MEM stuff, to see if I can actually use a dirty rectangle method in painting with a "brush". It's easy with drawsprite to a buffered screen, but the MEM thing is hopefully the start of a more complex  bit based process for painting.

I would really appreciate some educate eyes to see where I am messing up in my code. It's probably something very noobish, so please be gentle with that stick :)

Code: (glbasic) [Select]
// --------------------------------- //
// Project: mem2mem-paint-test
// --------------------------------- //

//we define our variables here
GLOBAL x,y,i,r,i, mx,my,mlb,mrb,c,cc,rr
GLOBAL brush%[], bground%[], dirty%[]


//we start with a white image to paint on - we stick to 640x480 with this test
CREATESCREEN 30, 99, 640, 480    //screen 30, sprite 99, our work area

//we now use our own screen to make our work area white
USESCREEN 30
DRAWRECT 0,0,640,480, RGB(255,255,255)

//we set up a new screen for a paintbrush image
CREATESCREEN 31, 100, 20, 20   //screen 31, sprite 100, brush size 20x20

//we switch to our paintbrush screen to create the brush
USESCREEN 31

//we use math to draw in circles
FOR r = 1 TO 10                                 //for radius 1 to 10. Half width of our brush = radius
FOR i = 0 TO 360                            //all around the compas
x = SIN(i)*r                            //1st part of a circle formula
y = COS(i)*r                            //2nd part of a circle formula
SETPIXEL x+10,y+10,RGB(100,100,100)     //0,0 is top left corner, so we offset drawing to middle of image
NEXT
NEXT

//our main game loop
WHILE TRUE

//we get the mouse state
MOUSESTATE mx,my,mlb,mrb

//if the left button is down, we MEM our brush onto the canvas
IF mlb =1 THEN drawBrush()


//we ensure that all final drawings go to the real screen
USESCREEN -1

//we draw our work area sprite onto the real screen
DRAWSPRITE 99, 0, 0

//use the brush as a mouse pointer
DRAWSPRITE 100,mx,my

SHOWSCREEN
WEND


FUNCTION drawBrush:   //we could use parameter, but for this test we use globals
LOCAL x = mx-9     //mouse x less half the brush width + center pixel
LOCAL y = my-9     //mouse y less half the brush height + center pixel
LOCAL w = x+19     //width of the brush less 1
LOCAL h = y+19     //height of the brush less 1
LOCAL r%,g%,b%,a%
LOCAL BGabgr%      //Background alpha, red, green, blue . .that's why it has a funny name
LOCAL DIRTYabgr%, BRUSHabgr%
LOCAL rr,yy

//grab the background work area
SPRITE2MEM(bground%[], 99)

//grab the brush
SPRITE2MEM(brush%[], 100)

//build the dirty rectangle
rr = -1 //inner rows
cc = -1                                                                          //inner columns
FOR r = y TO h        //for each row
    rr = rr + 1 //for each inner row
    cc = -1                                                                         //reset inner column for new row
FOR c = x TO w    //for each column
    cc = cc + 1 //for each inner column
BGabgr% = bground%[c + r*20]             //get a piece of our drawing buffer
DIRTYabgr% = BGabgr% //get the buffer into the dirty rectangle
BRUSHabgr% = brush%[cc + rr*20]          //get the brush
BGabgr% = bOR(DIRTYabgr%,BRUSHabgr%)    //add the brush to the diry rectangle
bground%[c + r*20] = BGabgr%                    //rebuild background from the rectangle
NEXT
NEXT

//Replace background with changes
MEM2SPRITE(bground%[], 99, 640, 480)

ENDFUNCTION


24
Thank you all for you most excellent suggestions. I shall certainly refer back to them when I am ready to post my lessons.
One very noob question though. A forum Blog? Where would I find this? Ok, that's 2 questions then :P

25
I find that bright kids need a challenge, and they really do amazing things if you give them fun toys. I hate boring classes, so really do try my best to provided courses that the kids enjoy. The course is only for the kids in our school in Pretoria though.
As long as you don't laugh at my mistakes, if you like, I can post some of my classes here once I have the tricky stuff worked out. It may also be a great way for the kids to reference the material online, and maybe also learn more about GLBasic from you boffs.

26
I wanted to update the whole screen in the game loop, which if you think of it is really very silly of me. I can see that I need to pre-create my brushes before the game loop, and then use them on a background screen to get the effect I want.

The thing is, that I need to be able to apply smudges, emboss, and a few other sort of fun effects at realtime with a brush, so I need to do this stuff from the draw loop.

I am now thinking of using the old "dirty rectangle" method, by grabbing only the small part of the screen under the brush, and then doing my MEM magic only on that captured part, and then replacing the result back onto the buffer.

Thanks very much for your input, it helped me to see where I was going wrong. I have some homework to do now that you have straightened out my thinking. 

27
Hi again,
I was curious to see if I would be able to make small images to be used for paintbrushes in a paint program that I have in mind. It's straight forward to make an image with a 2D painter, but wanted to try to dynamically make all kinds of "paint brushes", so that I do not have hundreds of brush images to clutter the place.

Background:
I wrote a little program that uses SPRITE2MEM and MEM2SPRITE just to see how things would work, since the documentation warns that GETPIXEL can be very slow. The program uses a linear-move (linear-swap without comparing) concept to play around with the pixels. It's a very crude program, but it's the speed of the program that has me a little concerned. The idea is to use a paintbrush image and mix it with a different image on another "screen/buffer" in order to get all sorts of fun filter brush effects.

Code: (glbasic) [Select]
// --------------------------------- //
// Project: spritememToy
// --------------------------------- //

LOCAL pxl%[]
LOCAL res
LOCAL w
LOCAL h
LOCAL x
LOCAL y
LOCAL sw
LOCAL sh
LOCAL barrel%
LOCAL i
LOCAL offs1, offs2

LOADSPRITE "prettyImage.png",0
GETSPRITESIZE 0,w,h
GETSCREENSIZE sw,sh
res = SPRITE2MEM(pxl%[], 0)

WHILE 1
FOR y = 0 TO h-1
FOR i = 0 TO w-1
offs1 = (w/2 + i) + (y*h)
offs2 = (w/2 + i+1) +(y*h)
barrel% = pxl%[offs1]
pxl%[offs1] = pxl%[offs2]
pxl%[offs2] = barrel%
NEXT
MEM2SPRITE (pxl%[], 0, w, h)
NEXT
DRAWSPRITE 0, sw/2-w/2, sh/2-h/2

PRINT w+" "+h, 10,10
SHOWSCREEN
WEND

Question:
There are nothing wrong with the MEM functions, but they may be too slow for what I have in mind. Are MEM functions the fastest way to manipulate pixels in an image, or is there a faster way?  I could go the INLINE route, but then it moves out of the realm of what I want to teach the kids in my computer lessons. I hope there is a solution, else I may have to leave out this fun little exercise in my course.
My program itself may also be the problem, and it is perhaps just too crude for the mission.

Edit: I've included the image I used for my tests.

[attachment deleted by admin]

28
There is a large difference in the project when a novice like myself attempts something, against when someone with a lot of experience does it. But I'll get there one day. 
Thank you for the link, The code gives me something to aspire to.  :nw:

29
This little project was inspired when I discovered that the print does not zoom very well. This solution uses a large font file, and allows you to zoom it smaller for different sizes.

The left alignment needs a little work, but I'll leave that to the experts to play with. Note that this does not use the built in PRINT command, but duplicates what it does.

Code: (glbasic) [Select]
TYPE _PRINTX
chr []
fontID
base
border = 2   //font border if used
fw = 64 + self.border    //font width
fh = 72 + self.border    //font height
count = 15

FUNCTION Init: font$
LOCAL i, j, c=-1, x,y
self.fontID = RND(1000)+1000
self.base = RND(10000)+2000
LOADSPRITE font$, self.fontID
FOR j = 0 TO 15  //change this to 31 to include high ascii values
FOR i = 0 TO 15
c = c + 1
x = i * self.fw
y = j * self.fh
CLEARSCREEN
DRAWSPRITE self.fontID, -x,-y
GRABSPRITE self.base + c, 0,0, self.fw, self.fh 
DIMPUSH self.chr[], self.base + c
NEXT
NEXT
CLEARSCREEN
ENDFUNCTION


FUNCTION _print: text$, x, y, scale#
LOCAL i,c, s$
FOR i = 0 TO LEN(text$)-1
s$ = MID$(text$,i,1)
c = ASC(s$)
ZOOMSPRITE self.chr[c], x + (i * self.fw *scale#), y, scale#, scale#
NEXT
ENDFUNCTION

ENDTYPE



LOCAL font1 AS _PRINTX   //define your own font object

font1.Init("arial72.png")  //initialize the font here

font1._print ("AbCdEfG 123", 0, 0, 0.2) 
font1._print ("Hello world", 0, 20, 0.2)
font1._print ("!@#$%^&*()_+", 0, 40, 0.3)
font1._print ("Is it a bird, is it a plane? No it's Super-GLBasic", 0 ,60, 0.18)
font1._print ("Eat your food to grow", 0, 80, 0.4)
font1._print ("even bigger", 0, 110, 0.6)
font1._print ("and bigger", 0, 140, 0.8)
font1._print ("Yum !", 30, 200, 1.5)
font1._print ("...oooOOOoooooo...", 20, 300, 0.5)

SHOWSCREEN
MOUSEWAIT

[attachment deleted by admin]

30
GLBasic - en / Re: Language support
« on: 2013-Jan-07 »
Yes it is very easy to print any character, but it takes a bit of work to set up.
The print uses a font image file, and you can use certain unused areas of the image file to make your own characters.

The first 32 character areas of the image file are "unused", and you paint you new characters into those. You will however need to print chr$(x) where x is 0 to 31. Then when you print that character, it gets its image from the location on the image file. This wont work with all character, since you cant really print them. Characters such as 9 is used for TAB, and wont print the character. 0 is NULL can may also not be printable. You will need to experiment.

How does this help you. Simply put a picture of å into one of the printable characters (background = black) and print it using that character number (x) where you put in in the image chr$(x)
The attached images show some changes I made to a font file, and the other image shows the results of the following program.

Code: (glbasic) [Select]
FOR i = 0 TO 45
PRINT CHR$(i), 10,i*10
NEXT
SHOWSCREEN
MOUSEWAIT

Edit: Remember to load the correct font image with LOADFONT
Sorry if I disagree with you spacefractal, but I use PRINT for many things, such as dynamically making buttons, changing button image text and so on.

[attachment deleted by admin]

Pages: 1 [2] 3 4