Is there a way to force all surfaces and textures to 32-bit pixels?

Game Development
1

First of all, my first post.
My apologies if I guessed wrong on where to post, I am unable to make sense of the discourse forum layout.
None of the navigation markers I am used to exist, thus I am left guessing on everything.
The thinking behind it’s layout is alien to me.
Infinite scroll on any page is insanity, generally meaning something overflowed, underflowed, or otherwise reached an undefined state.
Is there a way to turn that off, perhaps get a result count of a search, a sort by date, a category breakdown, or some sort of coherence?
Is there a plug-in to give it form or structure?

I am using SDL2 to open a window.
Creating a surface, populating it.
Then displaying it.

What I have run into first is that everything seems to have its own pixel format.
My desire is to have all surfaces and textures use the same 32-bit format.
RBGA8888 is fine, AGBR888 is fine.
I am hoping I don’t have to wrap everything to force it, that would take time.

While I can modify the source and recompile, that is suboptimal in my eyes.
I am hoping there is a setting somewhere I have missed.

I know SDL is supposed to conserve memory, however, in this application I know there will be plenty of ram and storage available, my concern is consistency.

I am hoping I simply missed some setting somewhere.
Thx.

2

You have to specify for each texture what its pixel format will be when you create it. If you’re using SDL_Renderer then it doesn’t really matter if they’re all the same pixel format or not, so long as they’re appropriate for the source image; the GPU will know what to do.

3

@sjr

Thank you for the reply, even if it as I feared.

Sorry if my question was stupid, but this is new territory for me programming wise.
The view point or approach of C, and especially C++, is somewhat alien to me
I prefer things less abstract than either of them.
Initially I tried playing with WXwidgets, but that got far to involved and complicated.
All I want is to open a window, import a graphic, then display it along with some text.

Once I make sense of wrappers or some equivalent I will make everything use the same pixel format without an intermediate step.
Right now I am still getting to know C++, C was bad enough to wrap my head around, but this is worse.

Is the logic or thinking behind SDL documented anywhere?
The net is overflowing with examples of every sort, which is hard to sort through.
The garbage google and other search engines call results now certainly doesn’t help.

Right now I am trying to give all my surfaces and textures the same pixel format so I have a known starting point.
Then I make my program as above.
Which I will then disassemble so I can walk through it, allowing me analyze it structurally in a more familiar manner to help me understand the logic of SDL.

4

I don’t know what “intermediate step” you’re talking about.

You load an image, then hand it over to SDL and tell it what the pixel format of the image is. If you want everything to be 32-bit RGBA, just make your images all that format.

You keep mentioning surfaces… are you doing software drawing (SDL_BlitSurface() etc) or hardware accelerated drawing with SDL_Renderer?

Also, I don’t see how looking at a disassembly of your program will help you understand SDL, but to each their own.

5

@sjr

I don’t have control of the images.
Besides, I don’t yet know the difference between cpu and gpu rendering calls in sdl.

I also want the font renderings to be the same.
So I allocated a surface
SDL_Surface* Gripe;
Make whatever call to allocate, load, etc, with that as target.
I then do
SDL_ConvertSurfaceFormat( Gripe, SDL_PIXELFORMAT_RGBA32, 0);

Thus everything ends up the same, which simplifies things since all formats are now the same, and in 32 bit clocks which is convenient for analysis…

Most of what I do is on things that don’t have any real interface, let alone a gui.
Most often it is a serial if I am lucky, or even just some lights.

For me, things either ‘click’ right away, or I have a long struggle ahead of me, which is as often as not, a waste of my time in the long run.
C & C++ are the opposite of ‘clicking’ in my case.
As for looking at the assembly, while it is some work, it is also consistent, which is what I need when learning something new.
I am not a ‘memorize now’ understand later sort of learner.
I need to understand the underlying structure from the beginning.
Only then can I see the patterns I need to use to accomplish my job.

Thx for your help.

6

Rendering on the CPU is gonna be way slower than using the GPU. When using the GPU, it doesn’t matter if the individual pixel formats are different. On the CPU, it’ll be faster if they’re the same format as the window’s surface, which might not be RGBA32.

7

@sjr

I understand that CPU is slower then GPU for most graphic/display purposes.
This isn’t about speed for me, or at least not yet.
This is about understanding the logic as it happens.
Abstraction is not my friend, it interferes with understanding and comprehension until I can map it out in my own terms, then I can deal with it.
Once I have it mapped out, when I see the upper layers in motion, I can “see” the lower levels now that I know what they are.
Without being able to “see” all the steps, I am unable to map out and follow the logic of the various state machines in motion.
For instance, It is how I explore the difference between Ladder and Pascal programs that do the same job, or are supposed to.
Basic is another, as are many others, it gets to be a mess.
By diving into the assembly, which I then map out.
(P.S. Ladder is an embedded control language for machinery.)
That compare and contrast is how I study and learn.

I am at the ‘What does this do?’ stage.
C & C++ are very hard for me to read, I dislike both, but they are both widely used, so I have to learn to deal with both, despite their messiness.

8

@Janus
If you want to understand precisely what happens (at the layer of bit pattern transfers in virtual memory-- i.e., not at the operating systems level, the physical memory level, or the circuit level etc.), then surfaces are likely to be easier to understand.
Most SDL users use SDL partly because they want to make efficient use of GPUs, so most current users will focus their knowledge on “renderer” and “texture” objects. These must be abstract, because different GPUs/graphics drivers use different “concretisations”.

Pascal and C are very similar languages, so you should be able to re-use your know-how from there. C’s type system and lack of nested procedures may be disappointing, of course, and the C preprocessor can make it hard to understand what is happening. Many compilers allow you to run the preprocessor over the source code by passing the ‘-E’ flag, which removes a lot of indirection.

If you want to have direct control and force a specific pixel format, try allocating an SDL_Surface structure yourself (e.g., in static memory or stack-dynamic memory), and populate all of its fields “by hand” before you blit.

Here is the documentation for the fields:

Note that I have not tried this myself, but I don’t see why it wouldn’t work. I don’t necessarily recommend using this technique in production code or when working with others, but for learning it may be what you are looking for.

Good luck!

9

@creichen

I understand, however, I am not using SDL for what most people are.
I don’t yet care about CPU vs GPU rendering stuff, I am at the explore logic stage.
The ability to alter or customize an existing program is not enough for me.
I have no specific goal beyond understanding the logic behind the guis themselves.

What I have done is allocate a surface I called Gripe.
When I read in a graphic or render a font, it is to Gripe.
I then use SDL_ConvertSurfaceFormat to give the final surface a predictable format made from whatever format Gripe is in this time…

I have written a crude routine of add border of color and width to a surface of known format.
Currently just altering existing pixels, next is adding the border to the outside, perhaps with padding inside or outside it.
Then I am going to try to give it things like rounded corners.
After that, maybe add shadows.
I can adapt the pixel alterations and coordinate adjustments to match other formats if I ever need to once the logic is done…

Get away from this “Modern” flat contrastless space wasting logic defying what is in my eyes pure unadulterated garbage calling itself an interface. W8+ and its ilk.

Sorry, that came out stronger than I intended.
I find “Modern” unusable.
I am used to the interface, whatever form it takes, and the job flowing together consistently.
Or to put it plainly, a zero knowledge system where the interface provides a starting place which the job then helps you navigate as you go.

My long term goal here is make a gui backend that makes sense to me.
I have tried to follow WxWidgets and SDL both, and gotten lost.
I tried to follow Gecko and Blink, but again, got lost.
The abstractions and platform specifics are to much for my current level of knowledge.
For now, I am sticking with Visualstudio, VS not VSC, which is a flat contrastless morass.
It also lacks things I use.
CB & CL despite my best efforts, just don’t work for me, perhaps later.

Ironically, I started in on SDL because phpsdl compiled easily, and phpwx didn’t.
I use php a lot for stuff, so it gave me a place to start.
Try and retry without having to recompile is nice.
I did than until I had a starting place, now I am playing in C/C++, and having lots of fun with pointer ping pong. :frowning:

Amusingly one rule I learned in pascal is even truer in C++.
An object, or class in C++, is a collection of values, and the means to manipulate them.
Making the values themselves private, and the interface to use them public has saved me so much time and effort so far.
The derived classes look a little funny reading them, but with an inline setting for get and set values in the parent classes, there is zero overhead at the assembly level when getting or setting values in a parent class vs the child.
You have to be careful of the size of functions you inline, which is why I keep it to get & set inline, but leave the rest as normal calls.

10

Maybe it would be easier with BasicC:

https://pl.wikibooks.org/wiki/BasicC

11

@ROSY

I appreciate the thought, but I am unable to read the page.

Besides, I am after the low level details that API abstraction is designed to hide away to make things easier.

Sadly, in my case, it just makes things harder for me since those are where I start learning instead of where most people do.