Flicker

[Peter]

Deleted...

[Charles Pegge]

Couldn't get it to stop flickering either. Is using a back buffer the only solution?

Charles

[efgee]

We have too less programmers here and too less challenge.
I think that OxygenBasic is too difficult for they.

I think one problem could be that Oxygen is still a moving target.

Also there are different style of coders:

1.) Some are interested in writing games... others may not
2.) Not many will choose to spend their free time with a compiler if they don't know if the code they wrote yesterday will work tomorrow. (that's why there is a V1 and V2 line of D compilers - D1 is not changing the syntax but gets only bug fixes, D2 is constantly changing until perfect solution found... but in time it will become the real deal)
3.) Some are interested in learning "how to build a compiler" but the code is too convoluted and hard to read for non-geniuses...
4.) Fill in your main focus...

There are sure more possibilities, but either way if there are not many users each section of the list above will get only 1 or 2 interested persons.

Example: I did not look at your little games and gfx stuff because it's not something I'm interested in; it doesn't mean your stuff is worthless though  
So keep doing what you are doing and have fun.

[Charles Pegge]

Thanks Peter, that works smoothly.

Setfont should pass an empty string, otherwise the autoconverter will pass "0" as the font name

SetFont 12,28,0,0

SetFont 12,28,0,""

I also found that number-to-string auto-conversion causes a memory leak, so I will post an update to fix this. Many thanks for exposing the bug

Charles

[Charles Pegge]

Hi Frank, (efgee)

The core Oxygen language is quite stable now. I have spent much of the last year filling in semantic holes and extending syntax flexibility.

Anyone who wants to write a compiler should try doing a scripting language or two first, discover how much effort is involved, then multiply by five! There are so many irregularities at the Operating system level the libraries and the processor architecture itself, making a large number of complex rules necessary. So I have my doubts as to whether I can make the compiler any simpler, but I aim to keep the entropy in the code to a minimum.

Charles

[Charles Pegge]

So simple! Thanks Peter.

My color variation:

Code: OxygenBasic

1.  
2. indexbase 0
3. Include "window.h"
4.  
5. SetWindow("Window",640,480,ws_overlappedwindow)
6. SetFont 18,48,0,"times"
7.  
8. While WinExit =0
9. cls 0
10. For y=0 To 480 step 20
11. For x=0 To 640 step 20
12. Circle bHdc,x,y,20,Rgb(10,Rand(180,200),Rand(180,255))
13. Next : Next
14.  
15. SetText "This is a water 3D effect",100,8,0xF8F880    
16. DoEvents
17. SwapBuffers
18. WaitTime 40
19. Wend
20. WinEnd
21.  

Charles

[Charles Pegge]

Okay, I have undoomed it.

Would this give ypu more flexibility? By changing DC pen and brush colors there is no need to create new pens and brushes then delete them.

in window.h
Bind gdi32
(
  GetStockObject   GetStockObject
  CreateSolidBrush CreateSolidBrush
 SetDCPenColor    SetDCPenColor
  SetDCBrushColor  SetDCBrushColor
 SetBkMode        SetBkMode
  SetBkColor       SetBkColor
)

...

sub SetColors(sys h,p,b)
SetDCPenColor h,p
SetDCBrushColor h,b
SelectObject h, GetStockObject (18) 'DC_BRUSH 18
SelectObject h, GetStockObject (19) 'DC_PEN 19
end sub
  

Example:

Code: OxygenBasic

1. indexbase 0
2. Include "window.h"
3.  
4. SetWindow("Window",640,480,ws_overlappedwindow)
5. SetFont 18,48,0,"times"
6.  
7.  
8. While WinExit =0
9. cls Rgb(10,200,200)
10. For y=0 To 480 step 20
11. For x=0 To 640 step 20
12. color1=Rgb(10,Rand(180,200),Rand(180,255))
13. SetColors bHDc,color1,color1
14. ellipse bHdc,x,y,x+40,y+40
15. Next : Next
16.  
17. SetText "This is a water 3D effect",100,8,0xF8F880    
18. DoEvents
19. SwapBuffers
20. WaitTime 40
21. Wend
22. WinEnd
23.  

Charles

[JRS]

Hi Peter,

I tried your Window example under Linux and it worked great until I closed the window with the X system menu button. It left a client area mess in my upper left corner of the screen.

John



[attachment deleted by admin]

[Charles Pegge]

I think the solution is to use a separate procedure for rendering which is invoked only when a WM_PAINT message is received. This will ensure that there is no attempt to paint after the window has been destroyed.

As I remember, this is how I solved this problem for the 3x3 magic square puzzle

Charles

[JRS]

Peter,

The latest version doesn't leave a orphan client area on my desktop after the close. Nice job!

John


[attachment deleted by admin]

[Charles Pegge]

Thanks Peter. I like plasma

Charles

[JRS]

Amazing what can be done with so little code.



[attachment deleted by admin]