On Tuesday 02 November 2010, at 05.15.55, "Mars_999" <mars999 <at> sio.midco.net> wrote:

> Hello, I am wondering how do I go about making a custom mouse cursor

> work in SDL/OpenGL? As of now I am guessing disable mouse cursor, switch

> to glOrtho() mode, render a fullscreen image with glRasterPos2i() to

> position the mouse cursor at mouseX, mouseY?

Why fullscreen? And why bother with glRasterPos2i() when in ortho mode?

All you have to do is pass the view size in pixels to glOrtho(), and handle the "wrong way" Y axis in one way or another. In this case, it's probably best to just swap the 0 and height to glOrtho() to get (0, 0) in the top-left corner, as it usually is with other APIs, SDL included.

--

//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.

| http://olofson.net http://olofsonarcade.com http://kobodeluxe.com |

'---------------------------------------------------------------------'

I figured I might as well throw a mouse cursor into Kobo II, as I'll need one sooner or later anyway, so here goes:

Matrix setup (origo at bottom-left, OpenGL style):

--8<-----------------------------------------------------------------

MatrixMode(PROJECTION);

LoadIdentity();

Ortho(0, screen.w, 0, screen.h, 0, 10);

MatrixMode(MODELVIEW);

LoadIdentity();

-->8-----------------------------------------------------------------

In the SDL event handling switch:

--8<-----------------------------------------------------------------

case SDL.MOUSEMOTION

{

mousex = ev.x;

mousey = screen.h - ev.y;

}

-->8-----------------------------------------------------------------

Rendering:

--8<-----------------------------------------------------------------

local cursorsize = 48;

Enable(BLEND);

BlendFunc(SRC_ALPHA, ONE);

Disable(TEXTURE_2D);

Begin(TRIANGLES);

Color(1, 1, 1, 1);

Vertex(mousex, mousey);

Color(1, 1, 0, 0);

Vertex(mousex + cursorsize * sin(PI/4),

mousey - cursorsize * sin(PI/4));

Vertex(mousex, mousey - cursorsize);

End();

-->8-----------------------------------------------------------------

(No, that's not C. It's EEL - but it's still SDL and OpenGL.

On Tuesday 02 November 2010, at 12.45.29, David Olofson <david <at> olofson.net> wrote:

> On Tuesday 02 November 2010, at 05.15.55, "Mars_999"

> <mars999 <at> sio.midco.net>

>

> wrote:

> > Hello, I am wondering how do I go about making a custom mouse cursor

> > work in SDL/OpenGL? As of now I am guessing disable mouse cursor, switch

> > to glOrtho() mode, render a fullscreen image with glRasterPos2i() to

> > position the mouse cursor at mouseX, mouseY?

>

> Why fullscreen? And why bother with glRasterPos2i() when in ortho mode?

>

> All you have to do is pass the view size in pixels to glOrtho(), and handle

> the "wrong way" Y axis in one way or another. In this case, it's probably

> best to just swap the 0 and height to glOrtho() to get (0, 0) in the

> top-left corner, as it usually is with other APIs, SDL included.

--

//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.

| http://olofson.net http://olofsonarcade.com http://kobodeluxe.com |

'---------------------------------------------------------------------'

On Wednesday 03 November 2010, at 10.55.43, "Gokotti" <gokotti <at> hotmail.com> wrote:

> Allright! Found it!

> The bug wasn't in the SDL itself. Minefield array tried to look squares out

> of indexes, never found them and so it went to a never ending loop...

Well, that's the way it is. For every ten lines of code, you have at least eleven opportunities of getting something non-obviously wrong.

> After I finish this project, I'm never gonna play minesweeper again!

You need to design more addictive games.

My metric is that if I get bored with the game while developing and testing it, the game design needs fixing.

That's a tall order indeed - but aim high and getting halfway there might be good enough.

--

//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.

| http://olofson.net http://olofsonarcade.com http://kobodeluxe.com |

'---------------------------------------------------------------------'

On Wednesday 03 November 2010, at 14.37.48, Marcos Marin <amcmr2003 <at> yahoo.com.br> wrote:

> Hello good people!

>

> Could anyone please point me to a previous thread or wiki article, or

> tutorial etc, that talks about direct pixel manipulation with SDL?

All you should need to get started is the documentation for SDL_Surface and SDL_PixelFormat. The rest is just good old low level computer graphics!

The easiest way is to just ask for 24 or 32 bpp software surfaces. SDL will usually be able to push that directly to the screen, and if not, it'll convert on the fly, possibly quick enough that your time is better spent optimizing your 24/32 bpp code than supporting multiple pixel formats.

> I mean, how easy or is SDL even the best approach to, say, the Demo

> Scene, for example.. instead of "simply" copying and pasting a bitmap on

> top of each other, like we all do =) how would you proceed on a lower

> level of control over your images and animations, and would that be

> efficient?

Short version: PC hardware (since the 486 or so) is not designed for software rendering.

Slightly longer version:

Since the PC architecture and video cards are designed for hardware accelerated rendering, CPU access to VRAM is about as far from optimal as it gets. The CPU will slow down to a crawl when doing it, no matter how fast it is, or what video card you have.

That said, with the CPU power available these days, software rendering is actually quite interesting, though the only realistic chances of getting the output to the streen at a usable frame rate is through OpenGL or Direct3D.

And, unless you need scalability to ancient hardware as well, maybe it's a better idea to just implement your software rendering as pixel shaders under OpenGL or Direct3D? That way, the work is done in the right place, by cost-effective hardware specifically designed for that kind of work. (You'd need an insanely fast CPU to come anywhere near the performance of an old budget 3D accelerator.)

That said, ZeeSpace is all software, and it'll probably stay that way for now. Then again, I'm not planning on using it for any massive real time rendering; only incremental background rendering and the occasional procedural texture.

> For example, another problem is the bitmap itself, I dont think we would

> be able to use any other image format to do this, since they're mostly

> compressed, making it harder to access individual pixels.. hence we would

> probably have to intercept SDL after it extracts it to memory anyway, thus

> it might not be so hard but, on the other hand, it perhaps might break

> portability?

There is no need to intercept! As long as you're not using RLE encoding/acceleration, the SDL surface is in precisely the format indicated by it's pixelformat field. That's all there is to it, pretty much.

> Sorry if this question is somehow inappropriate, I find it interesting

> though =) and seems seldom discussed, couldn't find much on the subject..

> =( so, any pointers in the right direction?

It's certainly interesting, and it's absolutely something you should try if you're serious about learning about graphics programming.

However, keep in mind that many of the methods and algorithms used for "traditional" software rendering, and the related optimization tricks, aren't really up to date with how modern CPUs and computers work. And, hardware accelerated rendering via high level APIs is a different beast entirely - except for the pixel shader bit.

--

//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.--- Games, examples, libraries, scripting, sound, music, graphics ---.

| http://olofson.net http://olofsonarcade.com http://kobodeluxe.com |

'---------------------------------------------------------------------'