• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
tmarques4

SDL_Surface question.

6 posts in this topic

Hello,

 

I'm trying to understand how SDL_surfaces work. When you set one with the SDL_HWSURFACE flag, are you storing the buffer to the GPU's memory? (Assuming there's a GPU to output video content)

 

If so, does the pixels parameter of the SDL_surface structure points to a position in the GPU's memory instead of the host's memory?

 

I tried reading the documentation http://sdl.beuc.net/sdl.wiki/SDL_Surface, but couldn't find the answer to that.

 

I apologise for any misunderstandings, I'm a newbie on this matter.

 

Thanks in advance!

0

Share this post


Link to post
Share on other sites

[quote]

If so, does the pixels parameter of the SDL_surface structure points to a position in the GPU's memory instead of the host's memory?

[/quote]

 

The "pixels" member is only accessible while the surface is [url="http://www.libsdl.org/docs/html/sdllocksurface.html"]locked[/url] or if the [url="http://wiki.libsdl.org/moin.cgi/SDL_MUSTLOCK"]SDL_MUSTLOCK[/url] macro evaluates as false. In the case of hardware surfaces, the idea is that  if necessary SDL_MUSTLOCK would evaluate as true, and that SDL_LockSurface() may copy the pixels into a in-memory buffer where they can be modified, and SDL_UnlockSurface() would update the GPU memory version.

 

This means that SDL_LockSurface() and SDL_UnlockSurface() would be quite expensive calls in such scenarios.

 

[quote]

When you set one with the SDL_HWSURFACE flag, are you storing the buffer to the GPU's memory?

[/quote]

Of course, that all depends on getting a real hardware surface to begin with. My understanding is that SDL's default backends on the major operating systems, as of version 1.2.X, do not support "hardware" surfaces. SDL 1.3/2.0 redesigned the rendering API to allow for hardware accelerated backends to be the default, but I have fallen behind on the status of this project so I don't know whether it is production ready yet. For the older version, I'd strongly recommend [url="http://www.oreillynet.com/pub/au/1205#Articles"]Bob Pendleton's SDL articles[/url] as particularly excellent.

1

Share this post


Link to post
Share on other sites

The 'SDL_HWSURFACE' refers to hardware blitting capability - ie. the sort of thing that DirectDraw implemented 10 years ago. It's not comparable in operation or speed to fully accelerated rendering (such as projects like SFML use). These days, it's likely that SDL_HWSURFACE is the worst of both worlds - blitting speed only marginally better than when done in software, with read and blending speeds crippled by comparison.

1

Share this post


Link to post
Share on other sites
This means that SDL_LockSurface() and SDL_UnlockSurface() would be quite expensive calls in such scenarios.

 

It's what I was afraid of, I don't want to move data from CPU to GPU as it's pointless and time consuming.

 

 

I'd strongly recommend Bob Pendleton's SDL articles as particularly excellent.

 

I've read the article about hardware surfaces (It's quite outdated) and there are some limitations, I'm having second thoughts about SDL not being the best of solution for me.

 

 

The 'SDL_HWSURFACE' refers to hardware blitting capability - ie. the sort of thing that DirectDraw implemented 10 years ago. It's not comparable in operation or speed to fully accelerated rendering (such as projects like SFML use).

 

I want read and write access to the buffer in video memory so I can process it with a OpenCL program, data would never be moved from one place to another. Is SFML a better solution for this? I'll look into it.

0

Share this post


Link to post
Share on other sites

[quote]

I've read the article about hardware surfaces (It's quite outdated) and there are some limitations, I'm having second thoughts about SDL not being the best of solution for me.

[/quote]

By dated do you mean simply old, or actually out of date? I'm not sure it is dated relative to SDL 1.2.X's implementation of hardware surfaces. I'm not aware of any major backend re-work in the mean time.

 

[quote]

I want read and write access to the buffer in video memory so I can process it with a OpenCL program, data would never be moved from one place to another.

[/quote]

Most such cross platform API's won't expose enough information to you to allow you to do this. I may be wrong, because I have not used SFML, nor OpenCL. Do you want to share the buffer between your rendering API and OpenCL?

0

Share this post


Link to post
Share on other sites
By dated do you mean simply old, or actually out of date? I'm not sure it is dated relative to SDL 1.2.X's implementation of hardware surfaces. I'm not aware of any major backend re-work in the mean time.

 

Just old, it was published in 2003.

 

 

Most such cross platform API's won't expose enough information to you to allow you to do this.

 

I understand, such API would have to be very low level to allow such access. Since SFML provides low level access to graphics, I think It might be a solution.

 

 

Do you want to share the buffer between your rendering API and OpenCL?

 

That's exactly what I want to do, use OpenCL to draw images to the buffer and using the rendering API (SDL, SFML...) to just update the buffer into the screen.

0

Share this post


Link to post
Share on other sites

So, I've learned about OpenCL and OpenGL being able to share image data (buffers), it's perfect since what I'm looking for is implementing a post-processing shader for applying special effects to a 3D scene, it's also efficient since data doesn't have to leave GPU's memory. I don't really have to worry about SDL or SFML as they don't affect this in any way.

 

Thanks again for all the help!

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0