1. SFML2 Demo Dilema - Solved

Hello,

I am having a bit of dilema trying to make a demo after wrapping SFML2. It involves trying to make a render window. Here is my euphoria code.

This is the C code I am trying wrap into Euphoria code.

sfVideoMode mode = {800,600,32}; 
sfRenderWindow* win; 
 
win = sfRenderWindow_create(mode,"SFML Win", sfResize | sfClose, NULL); 
 
if(!window) 
 return EXIT_FAILURE 
 
while (sfRenderWindow_isOpen(window)) 
{ 
  while(sfRenderWindow_pollEvent(window,&event)) 
  { 
   if(event.type == sfEvtClosed) 
   sfRenderWindow_close(window); 
  } 
 
  sfRenderWindow_clear(win,sfBlack); 
 
  sfRenderWindow_display(window); 
} 
 
sfRenderWindow_destroy(window); 
 
return EXIT_SUCCESS; 

--Flags 
public atom	sfNone = 0 
public atom	sfTitlebar = 1 
public atom     sfResize = 2 
public atom	sfClose = 4 
public atom	sfFullscreen = 8 
public atom	sfDefaultStyle = or_all({sfTitlebar,sfResize,sfClose}) 
 
public sequence sfWindowStyle = {sfNone,sfTitlebar,sfResize,sfClose,sfFullscreen,sfDefaultStyle} 
 
public enum type sfColor 
 
	sfBlack, 
	sfWhite, 
	sfRed, 
	sfGreen, 
	sfBlue, 
	sfYellow, 
	sfMagenta, 
	sfCyan, 
	sfTransparent 
	 
end type 
 
public enum type sfEventType 
 
	sfEvtClosed, 
	sfEvtResized, 
	sfEvtLostFocus, 
	sfEvtGainedFocus, 
	sfEvtTextEntered, 
	sfEvtKeyPressed, 
	sfEvtKeyReleased, 
	sfEvtMouseWheelMoved, 
	sfEvtMouseButtonPressed, 
	sfEvtMouseButtonReleased, 
	sfEvtMouseMoved, 
	sfEvtMouseEntered, 
	sfEvtMouseLeft, 
	sfEvtJoystickButtonPressed, 
	sfEvtJoystickButtonReleased, 
	sfEvtJoystickMoved, 
	sfEvtJoystickConnected, 
	sfEvtJoystickDisconnected, 
	sfEvtTouchBegan, 
	sfEvtTouchMoved, 
	sfEvtTouchEnded, 
	sfEvtSensorChanged, 
	sfEvtCount 
	 
end type 
--Graphics wrapper code 
public constant xsfRenderWindow_create = define_c_func(gfx,"sfRenderWindow_create",{C_POINTER,C_POINTER,C_UINT,C_POINTER},C_POINTER) 
 
public function sfRenderWindow_create(atom mode,sequence title,sfWindowStyle style,atom sett) 
 
 return c_func(xsfRenderWindow_create,{mode,allocate_string(title,1),style,sett}) 
	 
end function 
--Actual demo 
without warning 
 
include std/machine.e 
include EuSys2.ew 
include EuGfx2.ew 
 
include sfFlags.e 
 
sequence s 
 
--how to make the video mode sequence euphoria friendly? 
atom win = sfRenderWindow_create(s = {peeks(800),peeks(600),peeks(32)},"My Window", sfClose,0) 
 
if not win = 0 then 
	puts(1,"Could not create window!\n") 
	abort(0) 
end if 
 
while(sfRenderWindow_isOpen(win)) 
 
 while(sfRenderWindow_pollEvent(win,--what to put here?) 
 --key input 
end while 
 
sfRenderWindow_clear(win,sfBlack) 
 
sfRenderWindow_display(win) 
end while 
 
sfRenderWindow_destroy(win) 

Any help is greatly appericated. I'm mostly stuck with how to put the video mode in euphoria syntax and what to do about the event system using euphoria commands. I can post more code if it is needed.

new topic     » topic index » view message » categorize

2. Re: SFML2 Demo Dilema

Note: you can use {{{triple braces}}} to display general code or console text

sfVideoMode mode = {800,600,32}; 
sfRenderWindow* win; 
 
win = sfRenderWindow_create(mode,"SFML Win", sfResize | sfClose, NULL); 
 
if(!window) 
 return EXIT_FAILURE 
 
while (sfRenderWindow_isOpen(window)) 
{ 
  while(sfRenderWindow_pollEvent(window,&event)) 
  { 
   if(event.type == sfEvtClosed) 
   sfRenderWindow_close(window); 
  } 
 
  sfRenderWindow_clear(win,sfBlack); 
 
  sfRenderWindow_display(window); 
} 
 
sfRenderWindow_destroy(window); 
 
return EXIT_SUCCESS; 

new topic     » goto parent     » topic index » view message » categorize

3. Re: SFML2 Demo Dilema

Icy_Viking said...

sfVideoMode mode = {800,600,32}; 
win = sfRenderWindow_create(mode,"SFML Win", sfResize | sfClose, NULL); 

--how to make the video mode sequence euphoria friendly? 
atom win = sfRenderWindow_create(s = {peeks(800),peeks(600),peeks(32)},"My Window", sfClose,0) 

Oh no, definitely not that. Maybe constant mode=allocate(12); poke4(mode,{width,height,bpp}) but more likely you will have to wrap an sfVideoMode routine.

Icy_Viking said...

  while(sfRenderWindow_pollEvent(window,&event)) 

 while(sfRenderWindow_pollEvent(win,--what to put here?) 

My guess would be something like constant event = allocate(sizeof(sfEvent)) and use peek4s(event+??) to retrieve event.type, but you may well have to wrap a whole sfEvent class.

HTH, Pete

new topic     » goto parent     » topic index » view message » categorize

4. Re: SFML2 Demo Dilema

The problem with wrapping the sfVideoMode and sfEvent is that they're structs. I'm not exactly sure how I'd go about wrapping structs. I know the next version is supposed to have some struct support, but I'm using 4.0.5 at the moment.

new topic     » goto parent     » topic index » view message » categorize

5. Re: SFML2 Demo Dilema

Icy_Viking said...

The problem with wrapping the sfVideoMode and sfEvent is that they're structs. I'm not exactly sure how I'd go about wrapping structs.

I'm not a C programmer and I never had time to use it (some people still have to pick tomatoes...), so I've never used a C struct.

But long time ago, when memory was very limited, I had to create my own efficient data type in BASIC. So I've created a very short library with about 5 functions, that accepts a string argument, start_bit argument, and end_bit argument, for example:

data = "xyz"

data string was treated by my library simply as 24 bits (3 bytes * 8 bits).
if start_bit,end_bit arguments were, for example 6,12 then my library returned an integer of 7 bits (bits 6,7,8,9,10,11,12), which actually started at the first byte ('x') and ended at the second byte ('y').

This library was very short and efficient, using only a fast bit manipulation code.

In this way I could store in a string of any length, as many variables as I needed, including single bits, nibbles, integers, floating points (in IEEE format), other strings, actually any type of variable that exists on earth.

Creating such library is very easy, you need only few utility functions to create, modify, retrieve, and even search for specific data within a string (string in this case is treated at the bit level of course).

I don't know how complex is your C struct. But with that library I did magics, in memory and on disk.

new topic     » goto parent     » topic index » view message » categorize

6. Re: SFML2 Demo Dilema

Well the structs I may need to wrap are

typedef struct  
{ 
 unsigned int width; 
 unsigned int height; 
 unsigned int bitsPerPixel; 
} sfVideoMode; 
 
typedef struct 
{ 
 sfEventType type; 
 sfKeyCode code; 
 sfBool alt; 
 sfBool control; 
 sfBool shift; 
 sfBool system; 
} sfKeyEvent; 

And the event structs go on. I'm not exactly sure how I'd wrap C structs into euphoria code.

new topic     » goto parent     » topic index » view message » categorize

7. Re: SFML2 Demo Dilema

It looks too easy.

I don't know what sfEventType means (is it a WORD or what?), but for my old library it's a piece of cake... it's all about how many bits are in each data type.

new topic     » goto parent     » topic index » view message » categorize

8. Re: SFML2 Demo Dilema

sfEventType is the type of variable.

public constant xsfVideoMode = define_c_func(gfx,"sfVideoMode",{C_UINT,C_UINT,C_UINT},C_POINTER) 
 
public function sfVideoMode(atom w,atom h,atom b) 
 
 return c_func(xsfVideoMode,{w,h,b}) 
 
end function 

That is my idea of how you might wrap the struct, but I don't think you can wrap structs like that.

new topic     » goto parent     » topic index » view message » categorize

9. Re: SFML2 Demo Dilema

Shian_Lee said...

It looks too easy.

I don't know what sfEventType means (is it a WORD or what?), but for my old library it's a piece of cake... it's all about how many bits are in each data type.

It's an int. It's just a regular C++ enum. So is sfKeyCode. sfBool is also an int.

new topic     » goto parent     » topic index » view message » categorize

10. Re: SFML2 Demo Dilema

Since I'm not a C programmer, I've never had to use define_c_func(), and I don't remember what's on the manual as well...

But the difference between your example and my old library is that in your example you are using few variables, while my old library was just an intermediate utility to store and extract variables from a single string.

As far as I understand C struct, it's about a single pointer for continuous block of memory. So I assume that all you need is a pointer and a single string. If that's true, then the library I offered is just the utility to store and extract your variables from that string...

new topic     » goto parent     » topic index » view message » categorize

11. Re: SFML2 Demo Dilema

petelomax said...
Icy_Viking said...

  while(sfRenderWindow_pollEvent(window,&event)) 

 while(sfRenderWindow_pollEvent(win,--what to put here?) 

My guess would be something like constant event = allocate(sizeof(sfEvent)) and use peek4s(event+??) to retrieve event.type, but you may well have to wrap a whole sfEvent class.

HTH, Pete

Assuming that this is the sfKeyEvent struct, it'd look like this (4.0.5 compatible code):

-- sfKeyEvent has 6 members, all of them 4-byte ints 
constant event = allocate(4*6) 
-- note that allocate() returns a C pointer, which is the same thing that the &event stuff in C/C++ does. 
... 
 while(sfRenderWindow_pollEvent(win,event) 
... 
integer eventType = peek4s(event) 
integer code = peek4s(event+4) 
integer alt = peek4s(event+8) 
integer control = peek4s(event+12) 
integer shift = peek4s(event+16) 
integer system = peek4s(event+20) 

sfRenderWindow_create() looks more difficult to wrap, as it passes a struct directly (without a pointer). One possibility:

--Graphics wrapper code 
public constant xsfRenderWindow_create = define_c_func(gfx,"sfRenderWindow_create",{C_INT,C_INT,C_INT,C_POINTER,C_UINT,C_POINTER},C_POINTER) 
 
public function sfRenderWindow_create(integer width, integer height, integer bitsPerPixel,sequence title,sfWindowStyle style,atom sett) 
 
 return c_func(xsfRenderWindow_create,{width, height, bitsPerPixel,allocate_string(title,1),style,sett}) 
	 
end function 
 
atom win = sfRenderWindow_create(800,600,32,"My Window", sfClose,0) 
 

If that doesn't work, you might have no choice but to add an extra C wrapper to wrap sfRenderWindow_create() and then wrap the C wrapper in Euphoria.

new topic     » goto parent     » topic index » view message » categorize

12. Re: SFML2 Demo Dilema

Shian_Lee said...

As far as I understand C struct, it's about a single pointer for continuous block of memory. So I assume that all you need is a pointer

More or less. There are some annoying hiccups, however, like packing size/padding.

new topic     » goto parent     » topic index » view message » categorize

13. Re: SFML2 Demo Dilema

jimcbrown said...
Shian_Lee said...

As far as I understand C struct, it's about a single pointer for continuous block of memory. So I assume that all you need is a pointer

More or less. There are some annoying hiccups, however, like packing size/padding.

Well, that's what my old library did: not only storing variables, but also padding and aligning them, as fields in records.

With this kind of library you always deal with full struct, you don't really need to pass or accept individual variables.

new topic     » goto parent     » topic index » view message » categorize

14. Re: SFML2 Demo Dilema

Well it's almost working after I applied the changes you made Jim,

without warning 
 
include std/machine.e 
include EuSys2.ew 
include EuGfx2.ew 
 
include sfFlags.e 
 
atom win = sfRenderWindow_create(800,600,32,"My Window",sfClose,0) 
 
if not win = 0 then 
	puts(1,"Could not create render window!\n") 
	abort(0) 
end if 
 
constant event = allocate(4 * 6) 
integer eventType = peek4s(event) 
integer code = peek4s(event+4) 
integer alt = peek4s(event+8) 
integer control = peek4s(event+12) 
integer shift = peek4s(event+16) 
integer system = peek4s(event+20) 
 
while sfRenderWindow_isOpen(win) do 
	 
	while sfRenderWindow_pollEvent(win,event) do 
		 
	end while 
	 
	sfRenderWindow_clear(win,sfBlack) 
	 
	sfRenderWindow_display(win) 
 
end while 
 
sfRenderWindow_destroy(win) 

A window briefly appears, then closes. So I'm getting close.

new topic     » goto parent     » topic index » view message » categorize

15. Re: SFML2 Demo Dilema

Icy_Viking said...
constant event = allocate(4 * 6) 
integer eventType = peek4s(event) 
integer code = peek4s(event+4) 
integer alt = peek4s(event+8) 
integer control = peek4s(event+12) 
integer shift = peek4s(event+16) 
integer system = peek4s(event+20) 

That's similar to what I was taking about, but using an intermediate library, with resolution of bits lets you write more generic code, and with maximum flexibility about any kind of data type.

The code above is suitable for one case, but would be better to write intermediate library for all cases (it takes time, but the logic is simple).

new topic     » goto parent     » topic index » view message » categorize

16. Re: SFML2 Demo Dilema

Ok I got the window to stay open with this code. Now I just need to code the events so you can properly close the window, without it locking up the computer.

without warning 
 
include std/machine.e 
include EuSys2.ew 
include EuGfx2.ew 
 
include sfFlags.e 
 
atom win = sfRenderWindow_create(800,600,32,"My Window",sfClose,0) 
 
if win = -1 then 
	puts(1,"Could not create render window!\n") 
	abort(0) 
end if 
 
constant event = allocate(4 * 6) 
integer eventType = peek4s(event) 
integer code = peek4s(event+4) 
integer alt = peek4s(event+8) 
integer control = peek4s(event+12) 
integer shift = peek4s(event+16) 
integer system = peek4s(event+20) 
 
while sfRenderWindow_isOpen(win) do 
	 
	while sfRenderWindow_pollEvent(win,event) do 
		if sfeventType = sfEvtClosed then 
			sfRenderWindow_close(win) 
		end if 
        --This still dosen't close the window when clicking on the "X" button. Am I using it correctly? 
	end while 
	 
	sfRenderWindow_clear(win,sfBlack) 
	 
	sfRenderWindow_display(win) 
 
end while 
 
sfRenderWindow_destroy(win) 
new topic     » goto parent     » topic index » view message » categorize

17. Re: SFML2 Demo Dilema

I have to go now, so good luck.

Just remember that a regular string can be used as the most sophisticated struct that can be - if you simply treat it as a continuous stream of bits... But you must write the short library to store and extract variables from a string.

It might help if the data types are too complicated, and it gives you general solution for all cases.

new topic     » goto parent     » topic index » view message » categorize

18. Re: SFML2 Demo Dilema

Well I am getting closer to solving my dilema, I'm just stuck on one part.

without warning 
 
include std/machine.e 
include EuSys2.ew 
include EuGfx2.ew 
 
include sfFlags.e 
 
atom win = sfRenderWindow_create(800,600,32,"My Window",sfClose,0) 
 
if win = -1 then 
	puts(1,"Could not create render window!\n") 
	abort(0) 
end if 
 
constant event = allocate(4 * 6) 
integer eventType = peek4s(event) 
integer code = peek4s(event+4) 
integer alt = peek4s(event+8) 
integer control = peek4s(event+12) 
integer shift = peek4s(event+16) 
integer system = peek4s(event+20) 
 
while sfRenderWindow_isOpen(win) do 
	 
	while sfRenderWindow_pollEvent(win,event) do 
		if event = sfEvtClosed then 
			sfRenderWindow_close(win) 
		end if 
               if poke4(event,EventType) = sfEvtClosed then 
                   sfRenderWindow_close(win) 
               end if 
        --The top if statement, dosen't close the window when the user clicks on the X 
        --the bottom if statement comes up with an error when I try to run it.  
	end while 
	 
	sfRenderWindow_clear(win,sfBlack) 
	 
	sfRenderWindow_display(win) 
 
end while 
 
sfRenderWindow_destroy(win) 

Note I only have one if statement used at a time. I only included both for readability purposes and to see if there is anything I might be missing.

new topic     » goto parent     » topic index » view message » categorize

19. Re: SFML2 Demo Dilema

Icy_Viking said...

Ok I got the window to stay open with this code. Now I just need to code the events so you can properly close the window, without it locking up the computer.

You have a bit of code in the wrong place. Try this.

without warning 
 
include std/machine.e 
include EuSys2.ew 
include EuGfx2.ew 
 
include sfFlags.e 
 
atom win = sfRenderWindow_create(800,600,32,"My Window",sfClose,0) 
 
if win = -1 then 
	puts(1,"Could not create render window!\n") 
	abort(0) 
end if 
 
constant event = allocate(4 * 6) 
-- This is wrong. these shouldn't be here. No data is in event yet. 
-- These will be no more than random numbers. 
--integer eventType = peek4s(event) 
--integer code = peek4s(event+4) 
--integer alt = peek4s(event+8) 
--integer control = peek4s(event+12) 
--integer shift = peek4s(event+16) 
--integer system = peek4s(event+20) 
 
while sfRenderWindow_isOpen(win) do 
	 
	while sfRenderWindow_pollEvent(win,event) do 
	-- they belong down here instead 
integer eventType = peek4s(event) 
integer code = peek4s(event+4) 
integer alt = peek4s(event+8) 
integer control = peek4s(event+12) 
integer shift = peek4s(event+16) 
integer system = peek4s(event+20) 
		-- where did sfeventType come from? what is it's value? 
		-- it doesn't seem to be declared anywhere, let alone initialized 
		--if sfeventType = sfEvtClosed then 
		if eventType = sfEvtClosed then 
			sfRenderWindow_close(win) 
		end if 
	end while 
	 
	sfRenderWindow_clear(win,sfBlack) 
	 
	sfRenderWindow_display(win) 
 
end while 
 
sfRenderWindow_destroy(win) 

Note that I had the correct order in my original post:

jimcbrown said...
constant event = allocate(4*6) 
... 
 while(sfRenderWindow_pollEvent(win,event) 
... 
integer eventType = peek4s(event) 
integer code = peek4s(event+4) 
integer alt = peek4s(event+8) 
integer control = peek4s(event+12) 
integer shift = peek4s(event+16) 
integer system = peek4s(event+20) 
new topic     » goto parent     » topic index » view message » categorize

20. Re: SFML2 Demo Dilema

Thanks for the help. I overlooked the original post. I believe I am homing in on the problem. The window dosen't close still, but I believe there may be something wrong with how the flag type is declared, compared to what the C code is.

// C code from SFML 
typedef enum 
{ 
    sfEvtClosed,                 ///< The window requested to be closed (no data) 
    sfEvtResized,                ///< The window was resized (data in event.size) 
    sfEvtLostFocus,              ///< The window lost the focus (no data) 
    sfEvtGainedFocus,            ///< The window gained the focus (no data) 
    sfEvtTextEntered,            ///< A character was entered (data in event.text) 
    sfEvtKeyPressed,             ///< A key was pressed (data in event.key) 
    sfEvtKeyReleased,            ///< A key was released (data in event.key) 
    sfEvtMouseWheelMoved,        ///< The mouse wheel was scrolled (data in event.mouseWheel) 
    sfEvtMouseButtonPressed,     ///< A mouse button was pressed (data in event.mouseButton) 
    sfEvtMouseButtonReleased,    ///< A mouse button was released (data in event.mouseButton) 
    sfEvtMouseMoved,             ///< The mouse cursor moved (data in event.mouseMove) 
    sfEvtMouseEntered,           ///< The mouse cursor entered the area of the window (no data) 
    sfEvtMouseLeft,              ///< The mouse cursor left the area of the window (no data) 
    sfEvtJoystickButtonPressed,  ///< A joystick button was pressed (data in event.joystickButton) 
    sfEvtJoystickButtonReleased, ///< A joystick button was released (data in event.joystickButton) 
    sfEvtJoystickMoved,          ///< The joystick moved along an axis (data in event.joystickMove) 
    sfEvtJoystickConnected,      ///< A joystick was connected (data in event.joystickConnect) 
    sfEvtJoystickDisconnected,   ///< A joystick was disconnected (data in event.joystickConnect) 
    sfEvtTouchBegan,             ///< A touch event began (data in event.touch) 
    sfEvtTouchMoved,             ///< A touch moved (data in event.touch) 
    sfEvtTouchEnded,             ///< A touch event ended (data in event.touch) 
    sfEvtSensorChanged,          ///< A sensor value changed (data in event.sensor) 
 
    sfEvtCount,                  ///< Keep last -- the total number of event types 
} sfEventType; 

--Flag code 
public enum type sfEventType 
 
	sfEvtClosed, 
	sfEvtResized, 
	sfEvtLostFocus, 
	sfEvtGainedFocus, 
	sfEvtTextEntered, 
	sfEvtKeyPressed, 
	sfEvtKeyReleased, 
	sfEvtMouseWheelMoved, 
	sfEvtMouseButtonPressed, 
	sfEvtMouseButtonReleased, 
	sfEvtMouseMoved, 
	sfEvtMouseEntered, 
	sfEvtMouseLeft, 
	sfEvtJoystickButtonPressed, 
	sfEvtJoystickButtonReleased, 
	sfEvtJoystickMoved, 
	sfEvtJoystickConnected, 
	sfEvtJoystickDisconnected, 
	sfEvtTouchBegan, 
	sfEvtTouchMoved, 
	sfEvtTouchEnded, 
	sfEvtSensorChanged, 
	sfEvtCount 
	 
end type 
--Actual demo code 
without warning 
 
include std/machine.e 
include EuSys2.ew 
include EuGfx2.ew 
 
include sfFlags.e 
 
atom win = sfRenderWindow_create(800,600,32,"My Window",sfClose,0) 
 
if win = -1 then 
	puts(1,"Could not create render window!\n") 
	abort(0) 
end if 
 
constant event = allocate(4 * 6) 
 
while sfRenderWindow_isOpen(win) do 
	 
	while sfRenderWindow_pollEvent(win,event) do 
	 
	  integer eventType = peek4s(event) 
	  integer code = peek4s(event+4) 
	  integer alt = peek4s(event+8) 
	  integer control = peek4s(event+12) 
	  integer shift = peek4s(event+16) 
	  integer system = peek4s(event+20) 
	   
		if eventType = sfEvtClosed then 
			sfRenderWindow_close(win) 
		end if 
		 
	end while 
	 
	sfRenderWindow_clear(win,sfBlack) 
	 
	sfRenderWindow_display(win) 
 
end while 
 
sfRenderWindow_destroy(win) 
new topic     » goto parent     » topic index » view message » categorize

21. Re: SFML2 Demo Dilema

Icy_Viking said...

The window dosen't close still, but I believe there may be something wrong with how the flag type is declared, compared to what the C code is.

Ah, I forgot about this. I think with C, enums start from 0, but they start from 1 with Euphoria by default. Try this:

public enum type sfEventType 
 
	sfEvtClosed = 0, 
	sfEvtResized, 
	sfEvtLostFocus, 
	sfEvtGainedFocus, 
	sfEvtTextEntered, 
	sfEvtKeyPressed, 
	sfEvtKeyReleased, 
	sfEvtMouseWheelMoved, 
	sfEvtMouseButtonPressed, 
	sfEvtMouseButtonReleased, 
	sfEvtMouseMoved, 
	sfEvtMouseEntered, 
	sfEvtMouseLeft, 
	sfEvtJoystickButtonPressed, 
	sfEvtJoystickButtonReleased, 
	sfEvtJoystickMoved, 
	sfEvtJoystickConnected, 
	sfEvtJoystickDisconnected, 
	sfEvtTouchBegan, 
	sfEvtTouchMoved, 
	sfEvtTouchEnded, 
	sfEvtSensorChanged, 
	sfEvtCount 
	 
end type 
new topic     » goto parent     » topic index » view message » categorize

22. Re: SFML2 Demo Dilema - Solved

jimcbrown said...
Icy_Viking said...

The window dosen't close still, but I believe there may be something wrong with how the flag type is declared, compared to what the C code is.

Ah, I forgot about this. I think with C, enums start from 0, but they start from 1 with Euphoria by default. Try this:

public enum type sfEventType 
 
	sfEvtClosed = 0, 
	sfEvtResized, 
	sfEvtLostFocus, 
	sfEvtGainedFocus, 
	sfEvtTextEntered, 
	sfEvtKeyPressed, 
	sfEvtKeyReleased, 
	sfEvtMouseWheelMoved, 
	sfEvtMouseButtonPressed, 
	sfEvtMouseButtonReleased, 
	sfEvtMouseMoved, 
	sfEvtMouseEntered, 
	sfEvtMouseLeft, 
	sfEvtJoystickButtonPressed, 
	sfEvtJoystickButtonReleased, 
	sfEvtJoystickMoved, 
	sfEvtJoystickConnected, 
	sfEvtJoystickDisconnected, 
	sfEvtTouchBegan, 
	sfEvtTouchMoved, 
	sfEvtTouchEnded, 
	sfEvtSensorChanged, 
	sfEvtCount 
	 
end type 

Thanks Jim, it worked. Thank you all who have helped me with this dilema. Now I can finish writing out the rest of the demos and release the new SFML2 wrapper.

new topic     » goto parent     » topic index » view message » categorize

23. Re: SFML2 Demo Dilema - Solved

Here's the traditional way to wrap structures pre-4.1, which adds (will add?) memstruct support. Some knowledge of C is required to get this right, especially with type sizes and signage. Most structure elements are 4 bytes but some are more tightly packed. Unions and embedded structures can complicate matters. Adding to that, type sizes typically change between 32-bit and 64-bit (but not always), which is why we need memstruct support for 64-bit 4.1.

Basically, we define each offset as a constant, then we don't have to peek/poke with "magic numbers" in our code. This helps prevent bugs imposed by improper offsets in the structure, as well as adding to overall code clarity.

-- sfKeyEvent struct 
public constant 
    sfKeyEvent__event   =  0, -- sfEventType 
    sfKeyEvent__code    =  4, -- sfKeyCode 
    sfKeyEvent__alt     =  8, -- sfBool 
    sfKeyEvent__control = 12, -- sfBool 
    sfKeyEvent__shift   = 16, -- sfBool 
    sfKeyEvent__system  = 20, -- sfBool 
    SIZEOF_SFKEYEVENT   = 24, 
$ 
 
-- example: 
atom event = allocate_data( SIZEOF_SFKEYEVENT, 1 ) 
atom eventType = peek4s( event + sfKeyEvent__event ) 
atom code      = peek4s( event + sfKeyEvent__code ) 
-- etc. 

Here's how you'd do it with memstruct in 4.1.

public memtype 
    int as sfEventType, 
    int as sfKeyCode, 
    int as sfBool, 
$ 
 
public memstruct sfKeyEvent 
    sfEventType event 
    sfKeyCode code 
    sfBool alt 
    sfBool control 
    sfBool shift 
    sfBool system 
end memstruct 
 
-- example: 
atom event = allocate_data( sizeof(sfKeyEvent), 1 ) 
atom eventType = event.sfKeyEvent.event 
atom code      = event.sfKeyEvent.code 
-- etc. 

-Greg

new topic     » goto parent     » topic index » view message » categorize

24. Re: SFML2 Demo Dilema - Solved

One more.

typedef struct 
{ 
  unsigned int width; 
  unsigned int height; 
  unsigned int bitsPerPixel; 
} sfVideoMode; 

Traditional method..

-- struct sfVideoMode 
public constant 
    sfVideoMode__width        =  0, -- unsigned int 
    sfVideoMode__height       =  4, -- unsigned int 
    sfVideoMode__bitsPerPixel =  8, -- unsigned int 
    SIZEOF_SFVIDEOMODE        = 12, 
$ 
 
-- example 
atom mode = allocate_data( SIZEOF_SFVIDEOMODE, 1 ) 
atom width  = peek4u( mode + sfVideoMode__width ) 
atom height = peek4u( mode + sfVideoMode__heigth ) 
-- etc. 

and 4.1 with memstruct...

public memstruct sfVideoMode 
    unsigned int width 
    unsigned int height 
    unsigned int bitsPerPixel 
end memstruct 
 
-- example: 
atom mode = allocate_data( sizeof(sfVideoMode) ) 
atom width  = mode.sfVideoMode.width 
atom height = mode.sfVideoMode.height 
-- etc. 

I think you get the point. smile

-Greg

new topic     » goto parent     » topic index » view message » categorize

25. Re: SFML2 Demo Dilema - Solved

ghaberek said...

One more.

typedef struct 
{ 
  unsigned int width; 
  unsigned int height; 
  unsigned int bitsPerPixel; 
} sfVideoMode; 

Traditional method..

-- struct sfVideoMode 
public constant 
    sfVideoMode__width        =  0, -- unsigned int 
    sfVideoMode__height       =  4, -- unsigned int 
    sfVideoMode__bitsPerPixel =  8, -- unsigned int 
    SIZEOF_SFVIDEOMODE        = 12, 
$ 
 
-- example 
atom mode = allocate_data( SIZEOF_SFVIDEOMODE, 1 ) 
atom width  = peek4u( mode + sfVideoMode__width ) 
atom height = peek4u( mode + sfVideoMode__heigth ) 
-- etc. 

and 4.1 with memstruct...

public memstruct sfVideoMode 
    unsigned int width 
    unsigned int height 
    unsigned int bitsPerPixel 
end memstruct 
 
-- example: 
atom mode = allocate_data( sizeof(sfVideoMode) ) 
atom width  = mode.sfVideoMode.width 
atom height = mode.sfVideoMode.height 
-- etc. 

I think you get the point. smile

-Greg

Greg,... I'm not a C programmer but I get the point. It's very sad actually, from my point of view.

The traditional method is Euphoria code, clear, easy, works just fine. 4.1 memstruct is certainly not a breakthrough, yet it's overloading the language with additional C syntax.

Instead, you could just add a short tutorial to the manual for doing it right, and how to avoid crash. Or just add some safer utility to the STD library, written in "traditional" Euphoria.

It may avoid some peeking errors, but come on. Why don't you add string type to the language as well?...

new topic     » goto parent     » topic index » view message » categorize

26. Re: SFML2 Demo Dilema - Solved

Shian_Lee said...

It may avoid some peeking errors, but come on. Why don't you add string type to the language as well?...

It's already there: http://scm.openeuphoria.org/hg/euphoria/file/b9cba54d622a/include/std/types.e#l1209

new topic     » goto parent     » topic index » view message » categorize

27. Re: SFML2 Demo Dilema - Solved

Once 4.1 becomes officially available, I will rewrite the wrapper using the memstructs. Right now though, it is written in Euphoria 4.0.5 and everything works so far. I really hope 4.1 becomes an official release soon, I believe the memstructs will help out alot when wrapping C code. Might even help with wrapping C++ code as well. Also, I'll be using the 32-bit versions for compatbility reasons. I also saw that SFML 2.3 came out recently, so once the C binding gets updated for 2.3 I'll need to update EuSFML2 once again.

Edit: Added tilde (~) to "C++" to fix formatting. -Greg

new topic     » goto parent     » topic index » view message » categorize

28. Re: SFML2 Demo Dilema - Solved

jimcbrown said...
Shian_Lee said...

It may avoid some peeking errors, but come on. Why don't you add string type to the language as well?...

It's already there: http://scm.openeuphoria.org/hg/euphoria/file/b9cba54d622a/include/std/types.e#l1209

Come on... I mean really String type - not Euphoria-sequence. i.e. like single type - not atom.

new topic     » goto parent     » topic index » view message » categorize

29. Re: SFML2 Demo Dilema - Solved

Icy_Viking said...

Once 4.1 becomes officially available, I will rewrite the wrapper using the memstructs. Right now though, it is written in Euphoria 4.0.5 and everything works so far. I really hope 4.1 becomes an official release soon, I believe the memstructs will help out alot when wrapping C code. Might even help with wrapping C++ code as well. Also, I'll be using the 32-bit versions for compatbility reasons. I also saw that SFML 2.3 came out recently, so once the C binding gets updated for 2.3 I'll need to update EuSFML2 once again.

What can I say... it's almost like coding in C directly, and for C programmers it's great, as well as for Euphoria users who need these wrappers.

But in general, Euphoria 4 is getting more and more stuffy and with too many options, i.e.: not reliable.

new topic     » goto parent     » topic index » view message » categorize

30. Re: SFML2 Demo Dilema - Solved

Shian_Lee said...

What can I say... it's almost like coding in C directly, and for C programmers it's great, as well as for Euphoria users who need these wrappers.

There is simply no way to interface with external C libraries without having at least some basic understanding of C.

Euphoria's included memory management features actually make this much easier than other interpreted languages.

Shian_Lee said...

But in general, Euphoria 4 is getting more and more stuffy and with too many options, i.e.: not reliable.

I couldn't possibly agree with this statement. The memstruct features alone are a huge advantage. I've never had any reliability issues with any stable release of Euphoria. I've certainly tried out plenty of betas and nightly builds which were unreliable but those issues were promptly fixed.

I don't know why I'm arguing this though. I've been around Euphoria a long time now and it seems that with every generation of the language, there are naysayers who would prefer that the language stagnate and rot rather than improve upon itself over time.

-Greg

new topic     » goto parent     » topic index » view message » categorize

31. Re: SFML2 Demo Dilema - Solved

ghaberek said...
Shian_Lee said...

What can I say... it's almost like coding in C directly, and for C programmers it's great, as well as for Euphoria users who need these wrappers.

There is simply no way to interface with external C libraries without having at least some basic understanding of C.

Euphoria's included memory management features actually make this much easier than other interpreted languages.

Shian_Lee said...

But in general, Euphoria 4 is getting more and more stuffy and with too many options, i.e.: not reliable.

I couldn't possibly agree with this statement. The memstruct features alone are a huge advantage. I've never had any reliability issues with any stable release of Euphoria. I've certainly tried out plenty of betas and nightly builds which were unreliable but those issues were promptly fixed.

I don't know why I'm arguing this though. I've been around Euphoria a long time now and it seems that with every generation of the language, there are naysayers who would prefer that the language stagnate and rot rather than improve upon itself over time.

-Greg

totally agree. almost any other language is more likely to hang & crash on you or your users. though the silent exit problem can still exist with some as yet untested syntax, the reliability of the interpreter and compiler on debugged working code is unquestioned by all but a few who basically never build their own versions anyway so have only tried the earlier versions and even those not that much. it's impossible to make some people happy.

I would mention that it is 2015 and all the heavy lifting has been over for several years so fighting a "save developers time" angle is not really productive. people mostly work on what interests them. neither is is instructive to belabor how plain sequences and constants are just as effective as memstructs when you have never tried to fix win32lib or any large wrap and generally have no use for library written in other languages. we love syntactic sugar for a reason.

one other point: memstructs are in the menstruct branch and so far, the planned release of 4.1 won't include them nor do any of the alpha or beta. I have used memstruct quite a bit and never use any other euphoria except to build or test something.

new topic     » goto parent     » topic index » view message » categorize

32. Re: SFML2 Demo Dilema - Solved

ghaberek said...
Shian_Lee said...

But in general, Euphoria 4 is getting more and more stuffy and with too many options, i.e.: not reliable.

I couldn't possibly agree with this statement. The memstruct features alone are a huge advantage. I've never had any reliability issues with any stable release of Euphoria. I've certainly tried out plenty of betas and nightly builds which were unreliable but those issues were promptly fixed.

I don't know why I'm arguing this though. I've been around Euphoria a long time now and it seems that with every generation of the language, there are naysayers who would prefer that the language stagnate and rot rather than improve upon itself over time.

-Greg

Speaking of stagnation, when will the next stable version of Euphoria be released? 4.0.5 is too unstable (silent exit roughly 20% of the time) for *some* of my apps, even though they all run on the same base win32 library). I never was able to figure out the root cause (almost certainly some issue internal to Euphoria that the devs ain't yet fixed). The startup time for 4.0.5 is far too slow as well. The end result is that I and my users have to run my programs using 4.0.0 which, in not too many months, will be 5 years old...

ghaberek said...

.. The memstruct features alone are a huge advantage..

This is rather overstating it, don't you think? A bit like pouring a cup of hot water into a bath full of warm water. Yeah, there'll be an improvement but not by all that much. Will this "huge advantage" be in the next official release? Apparently not..

That certainly fits the definition of stagnating.

Spock

EDIT: I'm going to test the stability of the most recent beta version. Hopefully there has been an improvement because I don't really want to run stale software.

new topic     » goto parent     » topic index » view message » categorize

33. Re: SFML2 Demo Dilema - Solved

Spock said...

This is rather overstating it, don't you think? A bit like pouring a cup of hot water into a bath full of warm water. Yeah, there'll be an improvement but not by all that much.

The memstruct feature opens the door to cross-architecture programming (i.e. 32-bit or 64-bit). The traditional methods of structure wrapping I posted above really fall apart in the 64-bit world, because almost everything shifts up from 4 to 8 bytes wide (but not everything!). Having to manage a litany of ifdef's to provide this compatibility without memstruct is going to be tedious, at best.

Spock said...

Will this "huge advantage" be in the next official release? Apparently not..

Well, memstruct certainly should be included in the 4.1 release. I've used it quite a lot and I know Matt's fixed a lot of outstanding issues. What else remains?

-Greg

new topic     » goto parent     » topic index » view message » categorize

34. Re: SFML2 Demo Dilema - Solved

ghaberek said...
Spock said...

Will this "huge advantage" be in the next official release? Apparently not..

Well, memstruct certainly should be included in the 4.1 release. I've used it quite a lot and I know Matt's fixed a lot of outstanding issues. What else remains?

-Greg

Originally, it was held back for fear that it'd delay the 4.1.0 official release.

However, considering how hard it's been to move out of beta to 4.1.0RC1, and how much time and effort has been put in to finishing up the memstructs branch in the meanwhile, I think it's fair for us to reconsider that decision.

Should we vote?

new topic     » goto parent     » topic index » view message » categorize

35. Re: SFML2 Demo Dilema - Solved

jimcbrown said...

Originally, it was held back for fear that it'd delay the 4.1.0 official release.

However, considering how hard it's been to move out of beta to 4.1.0RC1, and how much time and effort has been put in to finishing up the memstructs branch in the meanwhile, I think it's fair for us to reconsider that decision.

Should we vote?

I vote that we vote. smile

-Greg

new topic     » goto parent     » topic index » view message » categorize

36. Re: SFML2 Demo Dilema - Solved

jimcbrown said...
ghaberek said...
Spock said...

Will this "huge advantage" be in the next official release? Apparently not..

Well, memstruct certainly should be included in the 4.1 release. I've used it quite a lot and I know Matt's fixed a lot of outstanding issues. What else remains?

-Greg

Originally, it was held back for fear that it'd delay the 4.1.0 official release.

I think there are still a few syntax choices that haven't been made. bitfields and ?? if Matt could say these could be finished without changing syntax already decided I don't see why anyone would object. there might be some bug reports and feature requests people have not entered tickets for yet? more unittests for coverage needed? docs?

jimcbrown said...

However, considering how hard it's been to move out of beta to 4.1.0RC1, and how much time and effort has been put in to finishing up the memstructs branch in the meanwhile, I think it's fair for us to reconsider that decision.

Should we vote?

switch tip to memstruct. moving it up in the roadmap won't be a huge surprise to anyone. has there been more than one no vote?

what are the download stats? how much actual use has the branch had to the extent we can know anything from hg.

new topic     » goto parent     » topic index » view message » categorize

37. Re: SFML2 Demo Dilema - Solved

Spock said...

Speaking of stagnation, when will the next stable version of Euphoria be released? 4.0.5 is too unstable (silent exit roughly 20% of the time) for *some* of my apps, even though they all run on the same base win32 library). I never was able to figure out the root cause (almost certainly some issue internal to Euphoria that the devs ain't yet fixed). The startup time for 4.0.5 is far too slow as well. The end result is that I and my users have to run my programs using 4.0.0 which, in not too many months, will be 5 years old...

That is the reason why I'm switching to wxEuphoria. It's not that different from win32lib. Once I understood how it worked and corrected some documentation errors, porting was relatively easy comparing to EuGtK. Now I have portable code running on both Windows and Linux.

To get it work, I had to use binaries included in wxide because official versions don't work with it and I didn't find the problem (parameters on an event routine).

Regards

Jean-Marc

new topic     » goto parent     » topic index » view message » categorize

38. Re: SFML2 Demo Dilema - Solved

I vote that the memstruct support is in the next release of Euphoria. Also, I like how my thread was hijacked from its original topic. Just joking. In regards to memstruct, I think it will help out alot of developers, and it will also make it easier to write wrapper libraries of other libraries for Euphoria.

new topic     » goto parent     » topic index » view message » categorize

39. Re: SFML2 Demo Dilema - Solved

Spock said...

Speaking of stagnation, when will the next stable version of Euphoria be released? 4.0.5 is too unstable .. The startup time for 4.0.5 is far too slow as well. The end result is that I and my users have to run my programs using 4.0.0 which, in not too many months, will be 5 years old... ..

Spock

EDIT: I'm going to test the stability of the most recent beta version. Hopefully there has been an improvement because I don't really want to run stale software.

Test Results using latest beta:

On my machine (Win7) Stability good, Startup slow
On a User machine (XP) program don't even start (or maybe it was starting but I shut it down after 5 mins)

Oh well, back to Dec 2010..

Yeah. You Devs are doing the right thing delaying the next release..

Spock

new topic     » goto parent     » topic index » view message » categorize

40. Re: SFML2 Demo Dilema - Solved

Maybe its too late :D but theres other ways to deal with structs in C without changing the syntax with the memstructs thing. A nice example is the newlisp FFI ( http://www.newlisp.org/downloads/newlisp_manual.html#importing_libraries ). They use libffi( https://sourceware.org/libffi/ ) to access C dlls.

new topic     » goto parent     » topic index » view message » categorize

41. Re: SFML2 Demo Dilema - Solved

This may, or may not, be something you can use, but I'll throw it out there for discussion:

SFML looks to be about as complex as GTK3, with lots of stuff to wrap. When I started working on EuGTK, I tried to link all the functions at startup. Not a good idea. Took forever to start up. Since GTK is object-oriented (as is SFML), I thought 'there's no use in linking functions that my program won't ever use', and so I link only the functions (methods) required for a given object that is declared in a program.

IOW, if your program creates a window, then the window methods (and inherited methods) are linked. If your program uses a button - or 100 buttons - the button class methods are linked (once). Not many programs are going to use more than a couple dozen object classes.

Perhaps - or not - the same approach could be used with SFML?

new topic     » goto parent     » topic index » view message » categorize

42. Re: SFML2 Demo Dilema - Solved

irv said...

This may, or may not, be something you can use, but I'll throw it out there for discussion:

SFML looks to be about as complex as GTK3, with lots of stuff to wrap. When I started working on EuGTK, I tried to link all the functions at startup. Not a good idea. Took forever to start up. Since GTK is object-oriented (as is SFML), I thought 'there's no use in linking functions that my program won't ever use', and so I link only the functions (methods) required for a given object that is declared in a program.

IOW, if your program creates a window, then the window methods (and inherited methods) are linked. If your program uses a button - or 100 buttons - the button class methods are linked (once). Not many programs are going to use more than a couple dozen object classes.

Perhaps - or not - the same approach could be used with SFML?

good point. link on first use would not be too difficult to setup. I don't use win32lib much, but, I wonder if this is part of the reason a large win32lib program takes longer to start up? maybe not that much since most of the win32lib demos startup in less than a minute on an underpowered Xp system.

also, if you qualify all the routines in your program startup is faster. since euphoria won't have to search for conflicts quite as much. this kind of thing. stdseq:split()

other things can add to startup time: how many paths will euphoria look at to resolve includes. run procmon or regmon, filemon to get an idea in windows. python has a commandline option to output to console its resolving paths while starting up. euphoria could use something similar.

run eu prog -w file to write out it's warning file some of the stdlib could use some cleanup again.

new topic     » goto parent     » topic index » view message » categorize

43. Re: SFML2 Demo Dilema - Solved

ne1uno said...

good point. link on first use would not be too difficult to setup. I don't use win32lib much, but, I wonder if this is part of the reason a large win32lib program takes longer to start up? maybe not that much since most of the win32lib demos startup in less than a minute on an underpowered Xp system.

Win32Lib already uses delayed-loading for system functions. See registerw32Function() and w32Func().

-Greg

new topic     » goto parent     » topic index » view message » categorize

44. Re: SFML2 Demo Dilema - Solved

Spock said...
Spock said...

Speaking of stagnation, when will the next stable version of Euphoria be released? 4.0.5 is too unstable .. The startup time for 4.0.5 is far too slow as well. The end result is that I and my users have to run my programs using 4.0.0 which, in not too many months, will be 5 years old... ..

Spock

EDIT: I'm going to test the stability of the most recent beta version. Hopefully there has been an improvement because I don't really want to run stale software.

Test Results using latest beta:

On my machine (Win7) Stability good, Startup slow
On a User machine (XP) program don't even start (or maybe it was starting but I shut it down after 5 mins)

Oh well, back to Dec 2010..

Yeah. You Devs are doing the right thing delaying the next release..

Spock

4.1 starts up faster than 4.0.x does. at this point only bug fixes are applied to 4.0.x

is there some reason you can't translate & compile the program to executable? or is the translated program starting up slow too?

recent 4.1 beta versions on the download page.

new topic     » goto parent     » topic index » view message » categorize

45. Re: SFML2 Demo Dilema - Solved

ne1uno said...

4.1 starts up faster than 4.0.x does. at this point only bug fixes are applied to 4.0.x

is there some reason you can't translate & compile the program to executable? or is the translated program starting up slow too?

recent 4.1 beta versions on the download page.

ATM I distribute a consolidated source file (41,609 net LOC) over our office network to update the main program. Compiling & distributing an exe doesn't really appeal to me for various reasons but no doubt it will be faster. I'll do some more tests. For our XP users I'd rather leave the Status Quo as is for them since 4.1 beta seems to be a non-starter anyway. (Our IT guy wants to upgrade all XP boxes but change doesn't happen fast for us due to time/budget/personalities..)

Spock

new topic     » goto parent     » topic index » view message » categorize

46. Re: SFML2 Demo Dilema

Shian_Lee said...

But long time ago, when memory was very limited, I had to create my own efficient data type in BASIC. So I've created a very short library with about 5 functions, that accepts a string argument, start_bit argument, and end_bit argument, for example:

data = "xyz"

data string was treated by my library simply as 24 bits (3 bytes * 8 bits).
if start_bit,end_bit arguments were, for example 6,12 then my library returned an integer of 7 bits (bits 6,7,8,9,10,11,12), which actually started at the first byte ('x') and ended at the second byte ('y').

This library was very short and efficient, using only a fast bit manipulation code.

In this way I could store in a string of any length, as many variables as I needed, including single bits, nibbles, integers, floating points (in IEEE format), other strings, actually any type of variable that exists on earth.

Creating such library is very easy, you need only few utility functions to create, modify, retrieve, and even search for specific data within a string (string in this case is treated at the bit level of course).

I don't know how complex is your C struct. But with that library I did magics, in memory and on disk.



Again, old friend, GMTA (great minds think alike)
It was exactly the way I created an extensive database once for keeping track of info
that had to be shared between programs that ran under MSDos,
simulating multi-tasking by having small parts of each program as TSR's
however, I did it in 8086 asm at the same time Win3.11 was conceived by Steve Jobs

new topic     » goto parent     » topic index » view message » categorize

47. Re: SFML2 Demo Dilema

I've updated the wrappers to make them more Euphoria friendly. I've also updated and fixed the demos. The update should be on the site within a few hours or so.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu