Messages

151

General discussions / Re: SFML 3 - What is your vision?

« on: September 14, 2014, 11:49:22 pm »

However there are discussions going on, on how to refactor the graphics code to make it possible, to implement different rendering back-ends, such as DirectX. How and if this will be done, is still in discussion.

I'm not downplaying the difficulty of this task.  However, this is highly desirable, from an SFML user perspective.

It is a make or break feature for any user or game studio evaluating SFML for use in a console game, or even a PC game with a potential console port down the road.  This is a large user base to turn away from SFML due to lack of necessary cross-platform support. 

It may be worth looking at Ogre3D's decoupling of RenderSystems (DirectX, GL, GLES) when considering a similar architecture for SFML. 

152

Graphics / Re: Guaranteed order of drawing quads within a VertexArray?

« on: September 01, 2014, 11:44:03 am »

Wow, that was fast! 
That's good news.  Thanks, Laurent.

153

Graphics / Guaranteed order of drawing quads within a VertexArray?

« on: September 01, 2014, 11:29:31 am »

Hi,

Here's a simple use-case to set the stage for my question.

I'm making a top-down view game.  I'm rendering a table top, with a plate on the table, and an apple on the plate.  I want to draw this with a single VertexArray (using a texture atlas) for performance / batch count reasons.  The table, plate, and apple are separate images within the atlas (and must be so, so different tables can have different items on top). 

So I make a VertexArray of Quads primitive type.  The VertexArray has 3 quads (12 verticies).

• The first quad is the table texture
• The second quad is the plate texture
• The third quad is the apple texture

Question:  Am I guaranteed that the apple will always be drawn overtop on the plate, and the plate overtop the table?  Or is there no guarantee of which order the quads within a VertexArray will be drawn?

Thanks for the help.

154

General discussions / Re: Better keyboard handling

« on: July 06, 2014, 10:09:31 pm »

I thought I'd add my experiences using OIS (object oriented input system) in a video game.  I think it mostly confirms what has already been decided.

OIS reports an OIS::KeyEvent when keyboard keys are pressed.

Code: [Select]

   class _OISExport KeyEvent : public EventArg
   {
   public:
      KeyEvent(Object* obj, KeyCode kc, unsigned int txt) : EventArg(obj), key(kc), text(txt) {}
      virtual ~KeyEvent() {}

      //! KeyCode of event
      const KeyCode key;
      //! Text character, depends on current TextTranslationMode
      unsigned int text;
   };
KeyCode is a scan code.  For game controls, you always key map using these KeyCodes (scan codes).
KeyCode is just a handy enum which enumerates the scan codes, presumably according to an American keyboard.

Code: [Select]

//! Keyboard scan codes
enum KeyCode
{
KC_UNASSIGNED  = 0x00,
KC_ESCAPE      = 0x01,
KC_1           = 0x02,
KC_2           = 0x03,
KC_3           = 0x04,
KC_4           = 0x05,
KC_5           = 0x06,
KC_6           = 0x07,
KC_7           = 0x08,
KC_8           = 0x09,
KC_9           = 0x0A,
KC_0           = 0x0B,
KC_MINUS       = 0x0C,    // - on main keyboard
KC_EQUALS      = 0x0D,
KC_BACK        = 0x0E,    // backspace
KC_TAB         = 0x0F,
KC_Q           = 0x10,
KC_W           = 0x11,
KC_E           = 0x12,
KC_R           = 0x13,
KC_T           = 0x14,
KC_Y           = 0x15,
KC_U           = 0x16,
KC_I           = 0x17,
KC_O           = 0x18,
KC_P           = 0x19,
KC_LBRACKET    = 0x1A,
KC_RBRACKET    = 0x1B,
KC_RETURN      = 0x1C,    // Enter on main keyboard
KC_LCONTROL    = 0x1D,
KC_A           = 0x1E,
KC_S           = 0x1F,
KC_D           = 0x20,
KC_F           = 0x21,
KC_G           = 0x22,
KC_H           = 0x23,
KC_J           = 0x24,
KC_K           = 0x25,
KC_L           = 0x26,
KC_SEMICOLON   = 0x27,
KC_APOSTROPHE  = 0x28,
KC_GRAVE       = 0x29,    // accent
KC_LSHIFT      = 0x2A,
KC_BACKSLASH   = 0x2B,
KC_Z           = 0x2C,
KC_X           = 0x2D,
KC_C           = 0x2E,
KC_V           = 0x2F,
KC_B           = 0x30,
KC_N           = 0x31,
KC_M           = 0x32,
KC_COMMA       = 0x33,
KC_PERIOD      = 0x34,    // . on main keyboard
KC_SLASH       = 0x35,    // / on main keyboard
KC_RSHIFT      = 0x36,
KC_MULTIPLY    = 0x37,    // * on numeric keypad
KC_LMENU       = 0x38,    // left Alt
KC_SPACE       = 0x39,
KC_CAPITAL     = 0x3A,
KC_F1          = 0x3B,
KC_F2          = 0x3C,
KC_F3          = 0x3D,
KC_F4          = 0x3E,
KC_F5          = 0x3F,
KC_F6          = 0x40,
KC_F7          = 0x41,
KC_F8          = 0x42,
KC_F9          = 0x43,
KC_F10         = 0x44,
KC_NUMLOCK     = 0x45,
KC_SCROLL      = 0x46,    // Scroll Lock
KC_NUMPAD7     = 0x47,
KC_NUMPAD8     = 0x48,
KC_NUMPAD9     = 0x49,
KC_SUBTRACT    = 0x4A,    // - on numeric keypad
KC_NUMPAD4     = 0x4B,
KC_NUMPAD5     = 0x4C,
KC_NUMPAD6     = 0x4D,
KC_ADD         = 0x4E,    // + on numeric keypad
KC_NUMPAD1     = 0x4F,
KC_NUMPAD2     = 0x50,
KC_NUMPAD3     = 0x51,
KC_NUMPAD0     = 0x52,
KC_DECIMAL     = 0x53,    // . on numeric keypad
KC_OEM_102     = 0x56,    // < > | on UK/Germany keyboards
KC_F11         = 0x57,
KC_F12         = 0x58,
KC_F13         = 0x64,    //                     (NEC PC98)
KC_F14         = 0x65,    //                     (NEC PC98)
KC_F15         = 0x66,    //                     (NEC PC98)
KC_KANA        = 0x70,    // (Japanese keyboard)
KC_ABNT_C1     = 0x73,    // / ? on Portugese (Brazilian) keyboards
KC_CONVERT     = 0x79,    // (Japanese keyboard)
KC_NOCONVERT   = 0x7B,    // (Japanese keyboard)
KC_YEN         = 0x7D,    // (Japanese keyboard)
KC_ABNT_C2     = 0x7E,    // Numpad . on Portugese (Brazilian) keyboards
KC_NUMPADEQUALS= 0x8D,    // = on numeric keypad (NEC PC98)
KC_PREVTRACK   = 0x90,    // Previous Track (KC_CIRCUMFLEX on Japanese keyboard)
KC_AT          = 0x91,    //                     (NEC PC98)
KC_COLON       = 0x92,    //                     (NEC PC98)
KC_UNDERLINE   = 0x93,    //                     (NEC PC98)
KC_KANJI       = 0x94,    // (Japanese keyboard)
KC_STOP        = 0x95,    //                     (NEC PC98)
KC_AX          = 0x96,    //                     (Japan AX)
KC_UNLABELED   = 0x97,    //                        (J3100)
KC_NEXTTRACK   = 0x99,    // Next Track
KC_NUMPADENTER = 0x9C,    // Enter on numeric keypad
KC_RCONTROL    = 0x9D,
KC_MUTE        = 0xA0,    // Mute
KC_CALCULATOR  = 0xA1,    // Calculator
KC_PLAYPAUSE   = 0xA2,    // Play / Pause
KC_MEDIASTOP   = 0xA4,    // Media Stop
KC_VOLUMEDOWN  = 0xAE,    // Volume -
KC_VOLUMEUP    = 0xB0,    // Volume +
KC_WEBHOME     = 0xB2,    // Web home
KC_NUMPADCOMMA = 0xB3,    // , on numeric keypad (NEC PC98)
KC_DIVIDE      = 0xB5,    // / on numeric keypad
KC_SYSRQ       = 0xB7,
KC_RMENU       = 0xB8,    // right Alt
KC_PAUSE       = 0xC5,    // Pause
KC_HOME        = 0xC7,    // Home on arrow keypad
KC_UP          = 0xC8,    // UpArrow on arrow keypad
KC_PGUP        = 0xC9,    // PgUp on arrow keypad
KC_LEFT        = 0xCB,    // LeftArrow on arrow keypad
KC_RIGHT       = 0xCD,    // RightArrow on arrow keypad
KC_END         = 0xCF,    // End on arrow keypad
KC_DOWN        = 0xD0,    // DownArrow on arrow keypad
KC_PGDOWN      = 0xD1,    // PgDn on arrow keypad
KC_INSERT      = 0xD2,    // Insert on arrow keypad
KC_DELETE      = 0xD3,    // Delete on arrow keypad
KC_LWIN        = 0xDB,    // Left Windows key
KC_RWIN        = 0xDC,    // Right Windows key
KC_APPS        = 0xDD,    // AppMenu key
KC_POWER       = 0xDE,    // System Power
KC_SLEEP       = 0xDF,    // System Sleep
KC_WAKE        = 0xE3,    // System Wake
KC_WEBSEARCH   = 0xE5,    // Web Search
KC_WEBFAVORITES= 0xE6,    // Web Favorites
KC_WEBREFRESH  = 0xE7,    // Web Refresh
KC_WEBSTOP     = 0xE8,    // Web Stop
KC_WEBFORWARD  = 0xE9,    // Web Forward
KC_WEBBACK     = 0xEA,    // Web Back
KC_MYCOMPUTER  = 0xEB,    // My Computer
KC_MAIL        = 0xEC,    // Mail
KC_MEDIASELECT = 0xED     // Media Select
};

Even though the KeyCode enum is non-localized, it makes no difference as it is only ever seen by the programmer.  Inside the keymap file, you associate controls with the numeric scancode, so this works regardless of language.

The only remaining problem is how you display these KeyCodes/scan codes in the key mapping user interface.

e.g. English:
Fire:   space
Reload:  left shift

vs. French:
Tirer:  maj gauche
Recharger:  espace


If SFML offered some kind of funtion like: 

Code: [Select]

  (w)char GetLocalizedKeyChar(unsigned int scanCode);or

Code: [Select]

  std::(w)string GetLocalizedKeyName(unsigned int scanCode);
Which translated a scan code to whatever primary character is on that key, that'd be awesome.  I don't know if this is possible.  Otherwise, it's just up to the game developer to pay a translator to do this for each language the game supports, and SFML can ignore this responsibility.

155

General / Re: Fixed timestep issue with box2d and sfml

« on: June 04, 2014, 07:33:47 am »

First off, I'd try it without the timestep, and see what happens.  If you still get artifacts, then maybe it's a vsync problem.  If you're running in fullscreen, try enabling vsync, or else try running in a window.

This line of code could also be a culprit.

Code: [Select]

const int clampedSteps = std::min(steps, MAX_STEPS);If MAX_STEPS is ever limiting steps, then you're going to get jittery movement.

What value for FIXED_TIMESTEP are you using?

156

General discussions / Re: SFML 3 - What is your vision?

« on: May 30, 2014, 06:47:01 pm »

Lower priorities, but still worth consideration would be:
1.  Particles
2.  Animation

I see Thor offers both these, but I haven't looked into it too much yet.

I think Particles would just be an overall win, and would find widespread use among SFML users.

Animation is tricky, because different folks will want to do it differently (e.g. sprite sequences vs 2D skeletons).  I suspect a lot of advanced users may end up coding their own anyway.  Still, a simple default implementation might do a lot to further increase the popularity of the library.

157

General discussions / Re: SFML 3 - What is your vision?

« on: May 30, 2014, 06:32:00 pm »

My SFML 3.0 priorities would be:
1.  continued focus on porting to new platforms
2.  performance enhancements (batching, atlases, etc)

I'm excited about the mobile device ports.  Anything that might help out with a console port would be equally awesome.  There's been a pretty big push from the console makers (especially PS4) to become more indie inclusive.

Thank you Laurent and the SFML Team for your great work.