Announcing the latest release of SDL_ttf!

http://www.libsdl.org/projects/SDL_ttf/

CHANGES:
 * Find the Unicode or symbol character map if it’s available in the font
 * Set the appropriate font styles for bold and italic fonts
 * Added font style TTF_STYLE_STRIKETHROUGH
 * Fixed size calculations taking outline and underline into account
 * Added API for font outlining: TTF_GetFontOutline()/TTF_SetFontOutline()
 * Added API to disable kerning: TTF_GetFontKerning()/TTF_SetFontKerning()
 * Fixed height calculation for fonts that extend below the font height
 * Added access to font hinting: TTF_GetFontHinting()/TTF_SetFontHinting()
 * Added TTF_GlyphIsProvided() to check whether a glyph is in a given font

Thanks to everybody who contributed feedback and patches for this release!
–
       -Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Bloc

Download

Blockzorz

Download

Falling in Pieces

Download

Tetris with a Twist

Download

Yage

Download

Zeetrix

Download

We had some amazing applicants for this year’s Google Summer of Code, and I would like to thank everyone who applied. It was very difficult to narrow down the final list, but in the end we picked 5 excellent students for this year’s project.

I’d like to introduce them and invite everyone to welcome them to the SDL community!

Introducing the Students:

* Daniel Wyatt is working on the Windows IME implementation, working with Jiang (a GSoC student from last year) to update the API and build working Japanese input support. I will be mentoring Danial and coordinating his collaboration with Jiang. You can find out more
about his project at:
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/sdl/t127230762719

* Eli Gottlieb is working on shaped window support for Linux, Mac OS X, and Windows. He will be mentored by Andreas Schiffler, who has
actually implemented shaped window support for commercial SDL projects. You can find out more about his project at:
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/sdl/t127230762740

* Jim Grandpre is working on adding support for multi-touch devices and developing a complete gesture recognition framework. He will be mentored by Ryan Gordon, who among many other things, is working on porting games to the iPad. You can find out more about his project at:
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/sdl/t127230762583

* Paul Hunkin is working on an official port of SDL 1.3 to the Android. I will be mentoring him and testing his code on my development Google Ion. You can find out more about his project at:
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/sdl/t127230762779

* Sunny Sachanandani is working on integrating X11 XRender support into SDL 1.3, with support for hardware accelerated blending and more.
I will be mentoring him and testing his code on a variety of Linux distributions. You can find out more about his project at:
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/sdl/t127230762857

Introducing the Mentors:

* Andreas Schiffler is an architect/dev for a commercial SDL based windows+linux application with shaped-window support. He is volunteering as a mentor this year to help Eli with his project.

* Ryan Gordon is a long time friend and SDL developer, and is currently rewriting the SDL multi-mouse support. He will be mentoring Jim on his touch input project this year.

* I am the original author of SDL and founder of Galaxy Gameworks LLC, a small company devoted to commercial development and support of
SDL 1.3 and beyond. I am looking forward to mentoring Daniel, Paul, and Sunny.

Welcome!
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

http://code.google.com/p/kizare/

Again, anyone interested in helping?

http://www.libsdl.org/hg.php

If you don’t use Mercurial and never want to, don’t worry, you can still grab snapshots from the SDL website and send patches the way you always have.

There are a number of reasons why this change was made, and here are a few:
* It’s much easier to iterate locally on changes before pushing them to the world, resulting in better code in the wild.
* It’s much easier to share changes with other people using Mercurial, which is great for the Google Summer of Code students. (e.g. hg export/import)
* It’s much faster to update and commit (or push and pull)
* Mercurial has similar syntax to Subversion for simple operations

Here is Ryan’s quickstart on Mercurial:

- The best quick-start tutorial I’ve read is Joel Spolsky’s new hginit.com. You should read it. It’s interesting and funny. I’ve read a lot of quick-start tutorials, and no other does it as well.

- The important thing to know, as a subversion user, is to stop fearing branching. Mercurial works best when you have a bunch of little ad-hoc branches weaving around each other.

- When committing new changes, keep the first sentence of the log comment short and on a line by itself. It’ll be used for the summary.

- More or less, most commands work like Subversion’s, and there is a TortoiseHg to match TortoiseSvn, if that’s you’re thing. But once you start using things that Subversion can’t do (bisect, record, shelve, rollback, queues, etc), you’re going to find yourself annoyed when you have to work with a Subversion repository and can’t use these extra features.

In case you’re curious, there’s lots of discussion on the why’s and wherefores on the SDL forums:

http://forums.libsdl.org/viewtopic.php?t=6047

See ya!
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Check it out here: http://www.appcelerator.com

That’s right, we’re back again for Google Summer of Code 2010!

Thanks to Google and the great students we’ve had, we’re going around for another year!

The Google Summer of Code is a program in which students from all over the world are invited to apply to help out open source projects over the summer for a significant stipend. Even if you’re not interested in helping out SDL, there are lots of great projects to choose from!

Please check it out on the SDL website at:
http://www.libsdl.org/gsoc.php

Because we’ve had applicants with widely varying skill levels, this year I’m asking all prospective applicants to submit a sample patch for SDL 1.3. It doesn’t have to be big or even accepted, but it does have to show familiarity with the development process and good coding practices.

Happy Coding!
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

Check out the Contest here.

I like how they added the ability to swap between two shapes, and how certain shapes group together.

The interesting thing about Pokemon Puzzle League is how the entire play area is really a cylinder that can rotate around.

Dr. Robotniks Mean Bean Machine is good in terms of multiplayer play.

Edit:
Alright, I’ll give it a shot and see how it goes.

Before we start, I’d like to say that this is an advanced SDL tutorial. You should have experience with creating SDL applications and some basic knowledge of getting a program with it’s libraries up and running.

First, we’ll start off with a very simple Game class to build the foundation of our demo project.

Game.h

Game.cpp

You should be able to compile and run at this point. Now we have a nice 800×600 window prepared for our bidding! The three double variables are used at keep track of elapsed time each tick. You can simply substitute in your favorite Timer class if you wish. I also turn off cursor visibility since we’ll be controlling an object with the mouse and we don’t want it to obscure our view.

Now we’ll need some sort of objects that we can collide together!

Entity.h

Simple enough, I hope. For each Entity we create, we’ll take in a filename for the for the image we’ll be loading. If you didn’t notice, SDL_image is included, as I’ll be working with PNG files with alpha transparency. Next, we take in the tiles across and tiles down in the spritesheet we’ll be using. Finally, a frame rate to determine how fast the sprite will animate.

Next, the member variables. I’ve created a simple Vector struct to hold position and origin information. Position is where the Entity will sit on the screen and origin is the center of the tile currently being drawn. This will make things simpler when we want to draw a sprite centered on it’s position. Of course, an SDL_Surface pointer to hold the image data we’ll be using. And last, variables to hold information about the spritesheet we’ll be using and handling animation.

Finally, two methods to update and render the given Entity. Now let’s implement these!

Entity.cpp

The constructor loads in our image using IMG_Load() and stores all our data about the sprite sheet. The destructor ensures we have no memory leaks by freeing our SDL_Surface. Update chips away at our frameTimeRemaining with a given deltaTime. Once we hit or are under zero, we increase the frame, wrap around to the beginning if need be, and reset our frameTimeRemaining with our given frameInterval. Render finds our location and clip rectangles and then blits the surface to the screen. But wait, we haven’t added GetBounds or GetFrameBounds() yet. I’m sure those will be useful to have! Let’s get to that!

Add these method definitions in:

Entity.h

And now we’ll implement them:

Entity.cpp

GetBounds() takes our position and shifts it over by our origin. This places the position at the center of the sprite, rather than the top left. GetFramesBound() checks what frame we’re on and finds the matching coordinates. Very important for animation!

Now lets slap a couple of these suckers into our demo!

Game.h

Make sure you include Entity.h so we can actually use the class and we’ll add two Entity pointers to our Game class.

Game.cpp

Image: Ship
Image: Asteroid
(Special thanks to 3DBuzz for these images.)

We’ll now dynamically allocate memory for our two new Entity objects. I have my images sitting in an “images” folder, but you may do whatever you want! I then position the asteroid at the center of the screen. And because we’re mindful programmers, we’ll delete the allocated memory once we’re all done.

Game.cpp

In OnThink, we’ll mouse movement to our ship by looking for an SDL_MOUSEMOTION event while polling for events. In OnUpdate, we’ll simply call each Entity’s Update method with the deltaTime we found. Lastly, in OnRender, we’ll just call the Render method by passing our screen.

Compile, run, and give it a whirl! Weeee! We now have two animated sprites, one centered in the screen and one controlled by our mouse. But where’s the collision? Oh yeah, we haven’t implemented it yet!

We’ll need a bit more functionally in our Entity class, so let’s work on that. This one’s a doozy, so hold on tight! But don’t worry, we’ll take it one step at a time…

Entity.h

Entity.cpp

Given the SDL_Rect of a collision rectangle, we want to find what pixels on the sprite sheet correlate to it. A little messy, but it gets the job done.

Entity.cpp

Given the two bounds of two entities, we want to find how much they intersect, if at all. If they do, we’re given their intersection rectangle, if not, we’re given an empty rectangle. For Max and Min, you can either include “cmath” or use a couple macros such as this:

Entity.cpp

This is where bulk of our per pixel collision check happens. First, we ensure there’s even a bounding box collision. No use going through all the trouble when we know nothing will happen. Then we normalize the bounds of each entity with the found collision rectangle. This will give us the region of pixels we’ll be comparing against each other. You’ll notice this GetAlphaXY() function. This is where we’ll get down into the pixels and determine if they’re solid enough for collision. You’ll see that it’s called twice in one if-statement. This is because we’re searching for a solid enough pixel in each surface at the same position. Once that is found, we’ll confirm a hit!

Entity.cpp

Oh my, some crazy looking stuff here! It’s not that bad. Let me explain a few things here.

We’re passing in a pointer to an Entity and an (x,y) coordinate. All we’re doing in this function is finding the pixel at that coordinate and determining what colors its composed of. The first two lines give us a pointer to the pixel in question. The funky looking switch-statement is finding the color composition depending on the image’s bytes-per-pixel format, either 8-bit, 16-bit, 24-bit, or 32-bit. In our case, it will always land on case(4), but this should give you an idea on how to expand to other formats.

Finally, we’re grabbing the RGBA components of the pixel using SDL_GetRGBA. All we care about is alpha, but you can experiment with collision where hits will only happen when a pixel is red or blue enough. Alpha will range between 0 and 255. I wanted collision to happen with not just pixels that were completely opaque, but not too transparent. I found 200 to be a nice number, but you’re free to tweak as you please.

Well that’s it! Our Entity class has the functionally to test for per pixel collision… so lets show it off!

Game.cpp

Adding this checks for collision between our ship and asteroid. When bounding box collision happens, a green box will be drawn behind them. When per pixel collision happens, the box will turn red!

Well, that’s about it. Run, compile, and enjoy! You now have per pixel collision checks between your two Entity objects! Feel free to tweak numbers, use different images, or control them in different ways! I’ve given you the foundation, now go out there and create some interesting implementations!

Here’s the final code in case you may have some errors and need to check against my own.

Game.h

Game.cpp

Entity.h

Entity.cpp

I hope you enjoyed my first tutorial for SDLTutorials.com and learned a lot! I plan to do more in the future!

SDL Per Pixel Collision – Tutorial Files:
Win32: RAR

In this tutorial, I will show you a simple c++ library to add network resources to your game.

Firstly, we have to add the SDL_net headers and libraries to your desktop environment. If you are using a linux distro like Ubuntu, it is enough to download the libsdl-netx.x-dev package from the repositories. If not, the process is analogous of including sdl mixer, image, etc, better explained by Tim’s Tutorials.
Don’t forget, as well, to set the linker options in your IDE, adding the SDL_net library.

So, let’s create our two files, CNet.h and CNet.cpp, that will build our framework that we’ll help us at making network games. It’s necessary to say that this library, for the time being, only works with TCP/IP protocol.

Here is our header file, and, after the includes and the charbuf declaration, our first class. Its aim is initialize and end the network environment, with two static functions. However, they are unnecessary, if we’re using SDL_Init(SDL_INIT_EVERYTHING).

The class above provides the needed interface for the application to deal with the packets sent through the network. It’s limited to a maximum of 256 bytes.

Regardless this class uses a buffer with a fixed length, the packets sent through the network can be much more smaller, according to the program’s needs. In our TIC TAC TOE game, only one byte is sent. To work with this customization, we put some message states, to help the framework user to build a derived class.

The LoadBytes and UnloadBytes member functions load and unload in a buffer the wanted chars. They were determined by the virtual functions NumToLoad and NumToUnload, each of which indicates how many bytes have to be loaded or unloaded. By default, this class is able to work with strings that have a maximum of 255 characters. If you want to work with other data structures, as we’ll do at the game making, you may override this member function.

Last, the finish() member function, which sets the class ready to be used. So, we can send through the socket, in the same packet, a message with two different data structures, avoiding unnecessary network pollution. Below, the implementation code of this and the latter classes:

Now, back to the header file. Let’s take a look at the CIpAddress class:

Basically, that is a C++ interface for the SDL NET structure IPaddress. It has informations about the host IP address, and the port which the program is associated to. Here is the definition of the class members, at CNet.cpp:

Again, back to header, let’s analyze CTcpSocket, a framework to the SDL NET TCP socket structure. In a few words, a socket is a connection, a “pipe” between two computers, that delivers messages to them, in and out. In a TCP socket, there are necessarily two fixed computers in each pipe’s end, and messages always are got in the right order that they have sent.

In the code above, the member function Ready() plays an important role: it checks whether there is or not activity in the socket, freeing the program’s flow to do what they have to do, without waiting messages from the other side of the pipe.
Below, the code in CNet.cpp:

From this class, we will derive CHostSocket, according to the piece of code of CNet.h:

A host socket is a socket whose utility is listen to a certain port, to check whether there is someone wanting to connect to the service provided by the program, in the machine it runs. If found, we have to use the member Accept to associate another socket to the client. Here is the implementation:

So, a tcp socket client is a socket whose aim is to communicate with a remote host, who, in turn, is using a tcp client to send and receive messages too. Below, the header file for this class:

The same way CHostSocket is, this class is derived from CTcpSocket, and uses the constructor or Connect() to make a connection to the host. If so, the object uses the Send() and Receive() member functions to throw and get messages through the network. Below, the implementation:

So that, we have finished the first part of our tutorial. Next, we’ll change the TIC TAC TOE source code to add playability over a network.

SDL Net Tutorial Files:
sdl-net-clientfiles.tar
sdl-net-commonfiles.tar
sdl-net-serverfiles.tar

So lets get started. Open up your project from the last tutorial. We’re first going to make a few prelimary changes. Make a new file called CEntityCol.cpp. Inside that file, put the following:

Now, get rid of that code from CEntity.cpp. I am basically moving the code to its own file so that everything is much neater. The second thing. Open up CEntity.h and change:

To this:

Also, change the void to bool in CEntity.cpp, CPlayer.h, and CPlayer.cpp. Why the change? Well, you’ll see in a minute.

We’re already storing the collision events in a queue, now we need to do something with them. Open up CApp_OnLoop.cpp. You’ll notice we already have a loop going for entities and we’re calling OnLoop. We’re basically going to do the same thing again, but after our first loop:

Not much going on here. We’re first iterating through every event in the queue. We then grab the two entities involved (EntityA, and EntityB), and we make sure they are valid pointers. If so, we first tell EntityA that it has collided with EntityB by calling OnCollision. Now, this is where that void to bool change comes in. EntityA can choose to prevent EntityB from knowing it has collided with him. If you remember, only Entities that are moving check for collision. This would mean EntityA is definitly a moving entity, and EntityB may or may not be moving.

Here’s an example to explain why you wouldn’t want to waste time calling EntityB’s OnCollision. Say you fire a bullet, and it hits a rock entity. Now, lets say the rock has a flag stating it’s indestructable. Our rock doesn’t care its been hit. So, when the OnCollision is called for the bullet, the bullet can see the entity it has hit is indestructable. And because of that, it can create a little “bullet being destroyed” animation, and then we can ignore telling the rock about it.

This is about the extent of entity collisions. So, now that we have this base, lets do something semi-useful with it.

Open up CEntity.h and add this new function, and variable:

Then, open up CEntity.cpp, and add the Jump function. Also make CanJump = false in the constructor:

Finally, go to the OnMove function. We’re going to figure out when our entity is allowed to jump. An entity is allowed to jump whenever it is touching the ground – or, in other words, whenever the entity is no longer moving on the positive Y-axis. So, at the top, we are first always going to reset CanJump to false:

Now, go down a bit, and modify the PosValid for the Y-axis to the following:

Now, to run through everything we did. First, we have a flag that states if an entity can jump. When set to true, we are allowed to call the Jump function. This CanJump variable is always false, unless our feet are on the ground. Whenever we actually do want to jump, we simply set our SpeedY in the negative Y-axis direction (up). Remember, gravity is always pushing us down, but at a slow speed. So, if we have a SpeedY of -5, and a AccelY of 0.75, we’ll move up for a time, gravity will kick in, and then we will eventually be pushed back down. Thus, giving the effect of a real jump. The trick here is to get the Speed and Acceleration variables just right.

Also, as a side note, the reason we made Jump return true/false is simply for informational purposes. Meaning, when a key is pressed by the player to jump, they won’t always be allowed to jump. And, if you wanted, you could do something based upon what Jump() returns.

So a few more tweaks before we try this out. In the constructor of CEntity, change the MaxSpeedX and MaxSpeedY to 10. Then, open up CApp_OnEvent.cpp and add the following to OnKeyDown:

And one last thing. Open up CPlayer.cpp, and change the OnCollision function to this:

That’s it! Compile, run, and have fun with Yoshi jumping all over the place. You’ll notice the simple collision event we added is that when Yoshi 1 collides with Yoshi 2, it causes Yoshi 1 to jump. Kind of lame, but you should get the idea.

SDL Collision Events – Tutorial Files:
Win32: Zip, Rar