Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: RenderWindow storage size unknown  (Read 4251 times)

0 Members and 1 Guest are viewing this topic.

deviouskoopa

  • Newbie
  • *
  • Posts: 6
    • View Profile
RenderWindow storage size unknown
« on: November 02, 2013, 12:01:44 am »
with sfFont, sfText, and sfRenderWindow, i want to initialize and create variables like:

sfVideoMode videoMode = { WINDOW_WIDTH, WINDOW_HEIGHT, BITS_PER_PIXEL };
sfRenderWindow renderWindow;
sfFont font;
sfText text;

&renderWindow = sfRenderWindow_create(videoMode, p_TITLE, sfDefaultStyle, NULL);
&font = sfFont_createFromFile(FILENAME_FONT);
&text = sfText_create();
 

but i get "storage size of RenderWindow isn't known" and similar errors. I don't really understand what the problem is, and CSFML's Types.h shows (which doesn't clarify anything for me):

typedef struct sfFont sfFont;
typedef struct sfRenderWindow sfRenderWindow;
typedef struct sfText sfText;
 

Can anyone explain my problem? Am I forced to initialize pointer types and _create functions while minding the scope? I'd ideally like to initialize the variables in one place then pass the pointers into a function that creates/sets their objects. This might not be possible though.

Thanks!

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: RenderWindow storage size unknown
« Reply #1 on: November 02, 2013, 12:16:37 am »
Yes, you have to use pointers.

Quote
&renderWindow = sfRenderWindow_create(videoMode, p_TITLE, sfDefaultStyle, NULL);
&font = sfFont_createFromFile(FILENAME_FONT);
&text = sfText_create();
This is not proper C syntax even.
Back to C++ gamedev with SFML in May 2023

deviouskoopa

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: RenderWindow storage size unknown
« Reply #2 on: November 02, 2013, 12:30:04 am »
Okay thanks, I wasn't sure how to handle this since "new" is called for me in the CSFML binding. Although creating and drawing to the window seems to work, I get 4 console errors of "warning: Invalid parameter passed to C runtime function" when I execute this last line in my debugger:

static const char p_TITLE[] = "Game Title";
const sfVideoMode videoMode = { WINDOW_WIDTH, WINDOW_HEIGHT, BITS_PER_PIXEL };
sfRenderWindow * p_renderWindow = NULL;
p_renderWindow = sfRenderWindow_create(videoMode, p_TITLE, sfDefaultStyle, NULL);
 

Can these warnings be safely ignored? I can't tell which param(s) is invalid.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: RenderWindow storage size unknown
« Reply #3 on: November 02, 2013, 11:59:53 am »
Okay thanks, I wasn't sure how to handle this since "new" is called for me in the CSFML binding.
Don't care about new, it's an implementation detail that doesn't concern you. CSFML could internally use an arbitrary allocator, don't assume anything about it.

sfRenderWindow * p_renderWindow = NULL;
p_renderWindow = sfRenderWindow_create(videoMode, p_TITLE, sfDefaultStyle, NULL);
What's the point of initializing the variable to NULL, just to overwrite it in the next statement? Furthermore, I would not use the Hungarian Notation (the "p_" prefix for pointers), it's a relict from ancient times.

Although creating and drawing to the window seems to work, I get 4 console errors of "warning: Invalid parameter passed to C runtime function" when I execute this last line in my debugger:
Your code looks correct, passing NULL for the context settings parameter is explicitly allowed. Might be a bug in the debugger or runtime environment.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

deviouskoopa

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: RenderWindow storage size unknown
« Reply #4 on: November 02, 2013, 03:59:02 pm »
Quote
Your code looks correct, passing NULL for the context settings parameter is explicitly allowed. Might be a bug in the debugger or runtime environment.

Thanks for the feedback, sounds reasonable so I'll ignore it. (As for Hungarian notation, I always use p_ and m_ out of habit; to each his/her own.)