What API do 2D MacOSX games use?

[joephish]

I'm hoping that this question hasn't already been asked lots of times before, but I was wondering what APIs all the shareware Mac OS X games use?

I got pretty far through developing a game using SDL (in pure C), but found it to be pretty frickin' slow for complete screen flips (I couldn't get double buffering to work for some reason either).

I had a look at SpriteWorld (soon to be 3.0) and SAT, but the way they handle graphics is confusing to me - I just want to be able to blit images onto a buffer with colorkeys, then flip front and back buffers.

The thing preventing me from going all out and learning Cocoa/ObjC properly is that I really wanted to make it cross platform to start with, and also I heard that Cocoa's Core graphics were really slow?!

I feel like I'm running out of options now. Should I be learning OpenGL even though I'm not doing anything 3D, just to get the speed of hardware acceleration?

[macboy]

Originally posted by joephish
Should I be learning OpenGL even though I'm not doing anything 3D, just to get the speed of hardware acceleration? Probably. :?:

[Josh]

OpenGL is very fast and very easy. Unless you want to target old computers, go with OpenGL.

[Ice Cream Joe]

I personally use a combination of SDL and OpenGL. The OpenGL is for all the graphics, and SDL is for the rest of the application. If you have most of a game already in SDL, just replacing the graphics with OpenGL shouldn't be nearly as hard as rewriting the whole thing. OpenGL is also cross platform.

And OpenGL works just as good for 2D games as it does for 3D. You can also take advantage of its rotation and blending functions (not to mention the hardware acceleration.)

(Edit: If you use OpenGL, you can also use GLUT, which can handle basic event loops and such. Very easy stuff if your game is relatively simple.)

[Zwilnik]

I switched to OpenGL at the start of the Airburst Extreme project and it's definitely the way to go for 2D games, especially if you're targetting OS X.

[Tycho]

I got pretty far through developing a game using SDL (in pure C), but found it to be pretty frickin' slow for complete screen flips (I couldn't get double buffering to work for some reason either).


The Mac OS X SDL implementation seems rough in a few areas. From my experience, due to the way OS X works, every window you create is double buffered, whether you specify it or not. That means that if you are doing your drawing to an offscreen buffer and then copying that to the screen, you are effectively triple buffering. You can just create a window without double buffering specified, and use something like
SDL_UpdateRect(surface, 0, 0, 0, 0);
to flip the buffers.

[joephish]

Ice Cream Joe - what do you mean you use SDL for the rest of the application? You use it's other capabilities such as audio etc?

Tycho - yeah I've tried looooads of different stuff. I even started doing really complicated stuff with detecting which bits I need to redraw and using UpdateRect properly, but even that got slow! (I'm sure i didn't have a bottleneck elsewhere either). I'm just really tired with fussing about with it.

You guys have made up my mind now though - I'll definitely be going with OpenGL. Sounds like the answer to my problems, and will be crossplatform. Thanks!

[Tycho]

What I'm saying is that you can just create a window as if it were single buffered and draw directly to it. Since all windows are really double buffered in OS X, calling UpdateRect basically flips the buffers. If this is still too slow (or if you've already tried it), then OpenGL would be a good choice. It's really not much harder than using SDL, and you get lots of useful stuff for free.

[Ice Cream Joe]

Originally posted by joephish
Ice Cream Joe - what do you mean you use SDL for the rest of the application? You use it's other capabilities such as audio etc?

Yeah. Pretty much everything that isn't graphics.

Although, for audio I strongly considered FMOD. I ended up going with SDL_mixer- mostly because I just wanted to learn it and get practice using it. The audio that comes with SDL proper was a little too low level for me, and doesn't really offer any additional capability than SDL_mixer.

[Mars_999]

SDL has a problem with double buffering in OSX.

Q: Why doesn't page flipping work?
A: The SDL_DOUBLEBUF flag (and hence page flipping) is unsupported on Mac OS X. There is no support in the operating system for this feature.

Prior to version 1.2.6, SDL did not report an error when SDL_DOUBLEBUF was used, but instead returned a single-buffered surface. This resulted in various visual anomalies, depending on the application.

The only good alternatives are to use a software surface instead (SDL_SWSURFACE), or use OpenGL. With OpenGL, you'll have to write your own blitting engine, or borrow someone elses.


Use OpenGL with SDL and if you're are not interested in Perspective viewing use Ortho projection for 2D games.

[GoodDoug]

I've done plain Quartz (ZedNought and upcoming game) and OpenGL (Headache) for 2D graphics. Both are useful and usable. I think that in the end, OpenGL may provide slightly more headaches, but is slightly faster. So, if you want something easy, that won't be too taxing... try Quartz. If you don't mind getting your hands dirty, and you need the speed, go OpenGL.

I can't comment on SDL, as I haven't used it.

[cheez0r]

Hmm.. I'm interested in this type of thing. Making a 2D game using OPenGL, but I haven't found TOO much info on it, what's this ORTHO projection?
also, by doing this, i'd be able to use 3D Models in the game and full animate them, etc? I plan on using a top-down 2D view for the game, but using models as the 'pieces'

[skyhawk]

orthographic view means there is no perspective... that means when looking top down, things on the right of your screen look the same on the left, bottom, top, anywhere, just like in a normal 2D game. You can use 3D models just like you normally would (I tried this in my game BOB2 and got some odd blending problems, but I used some workarounds so you never notice ;) )

[cheez0r]

yeah i opened up my opengl book and was like 'i'm dumb' after asking that question ;)

[AJ Infinity]

Don't forget about kelvin's CocoaBlitz.

[Criollo]

Ok, pardon my ignorance, but isn't OpenGL a 3D API used for drawing polygons and such? How would one use it in a 2D game?

-Criollo

[OneSadCookie]

OpenGL is a general-purpose graphics API, capable of taking advantage of hardware acceleration provided by 3D graphics cards.

Essentially, don't use perspective, just draw in the plane of the screen.

[DJBlufire]

A more specific answer to Criollo's question:

You can use OpenGL work with 2D graphics by using textured 2D quads. In other words, you draw all of your 2D images onto 2D squares that face the camera. Not that i've figured out how to get that working, though... ;D

So these questions go out to anyone who's had experience with that:
How do you deal with different window resolutions when in orthographic mode if the units you use to draw to the window are in pixels?
To get the textures to draw onto quads, do you load a 256x256, 512x256, etc. texture and then use texture coordinates in pixel units to load the correct part of the texture?

Thanks... I'm doing a 2D sprite game for a final project for my C++ class :D

[AJ Infinity]

You use an orthographic viewing projection also. Read the Red Book (chapter 3, to be exact) for more.

[Mars_999]

Originally posted by DJBlufire
A more specific answer to Criollo's question:

You can use OpenGL work with 2D graphics by using textured 2D quads. In other words, you draw all of your 2D images onto 2D squares that face the camera. Not that i've figured out how to get that working, though... ;D

So these questions go out to anyone who's had experience with that:
How do you deal with different window resolutions when in orthographic mode if the units you use to draw to the window are in pixels?
To get the textures to draw onto quads, do you load a 256x256, 512x256, etc. texture and then use texture coordinates in pixel units to load the correct part of the texture?

Thanks... I'm doing a 2D sprite game for a final project for my C++ class :D

Ah I am confused? But if you're asking what textures do I use to map onto a quad? You can load up any texture size e.g. 256x256 or 128x128 and assign that texture to a quad of whatever size you want.

[OneSadCookie]

One typical orthographic viewing projection is pixel-perfect, but it doesn't have to be... For example I have code (in Astro, uDevGame 2001 entry, actually) which picks out a 4:3 viewing area with coordinates 0..1,0..0.75 in a window of any size and shape...

The easiest approach to doing your graphics would be to create one texture per frame per sprite. Not the most efficient, but it would work.

You can't take portions out of textures using pixel coordinates without using EXT_texture_rectangle, but the idea's basically right (just normalize the pixel coordinates to 0..1 based on the width).

[Criollo]

From what I hear, using OpenGL is supposed to be faster than using Quartz for 2D graphics. So mapping a texture onto a quad is faster than creating an NSImage, and compositing it to the screen? How's that work out?

-Criollo

[DJBlufire]

I don't know about the speed difference in that particular case, but I'm pretty sure that Quartz is slower when it comes to larger images and when compositing/blending is involved.

[Carlos Camacho]

Something about games that use OpenGL that gets my attention. I'm not sure how to explain it. Click on the game, screen switches rez and what not nd then game comes up. Not sure if it is OpenGL rendering, or the use of some low rez mode but OpenGL seem "blurry", for lack of better word. Sorry not to be more technical. Is it me, or is this just something that is part of OpenGL and we must live with?

[DJBlufire]

I know what you're talking about! I think it's just how OpenGL puts stuff together... blah i dunno. It's probably some anti-aliasing thing that OpenGL automatically does for textures it has to scale up or down.

[OneSadCookie]

OpenGL doesn't have to be blurry (look at your Quartz Extreme enabled screen; that's all drawn with OpenGL).

I don't know what effect you're referring to, but obviously anything that's been scaled larger than its original size will seem blurry.

When you call glTexImage2D, that image is uploaded to video memory. Then when you come to draw it to the screen, it only has to go VRAM->VRAM, which is very fast. All that has to be sent to the video card each frame is where to draw the image.

Usually 2D drawing all happens in main memory, then the image is sent to the video card, along with the information about where to draw it. For (I hope now) obvious reasons, this is quite a bit slower than the OpenGL way.

[Mars_999]

Originally posted by OneSadCookie
OpenGL doesn't have to be blurry (look at your Quartz Extreme enabled screen; that's all drawn with OpenGL).

I don't know what effect you're referring to, but obviously anything that's been scaled larger than its original size will seem blurry.

When you call glTexImage2D, that image is uploaded to video memory. Then when you come to draw it to the screen, it only has to go VRAM->VRAM, which is very fast. All that has to be sent to the video card each frame is where to draw the image.

Usually 2D drawing all happens in main memory, then the image is sent to the video card, along with the information about where to draw it. For (I hope now) obvious reasons, this is quite a bit slower than the OpenGL way.

I don't understand? :) :wow: :p

DO NOT reply to that just joking!

[DCoder]

So, maybe I'm a little late jumping in here, but I have to weigh in my $0.02, since I have recently made similar decisions. For the record, as I started making my decision, I was sort-of familiar with SDL and mostly not familiar with OpenGL. In general, it's hard to find 2D information on OGL, whereas there are several 2D SDL tutorials around. Ultimately, I chose SDL just because I was a little more comfortable with it and I kept having trouble trying to get an ortho projection working in OGL.

But, for the record, if I had known about this tutorial (http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=21) (NeHe lesson 21) before I began coding, I probably would have chosen OGL instead. That, plus Apple's Red Rocket (http://developer.apple.com/samplecode/Sample_Code/Graphics_3D/Red_Rocket.htm) sample code provide just about enough core material to document what's necessary for doing a 2D OpenGL game (The trick with the Red Rocket sample is to cull out just the interesting OpenGL stuff and put the peripheral imaging parts off until later). As a corrollary to choosing OpenGL, I recall that not too long ago, OSC mentioned that it's impossible to do pixel-perfect collision detection with textures in OGL, so I'm kinda curious about what other methods ppl may have chosen for doing 2D collisions in OGL...

Fundamentally though, I wish there were more explanatory tutorials on 2D OpenGL stuff. If anybody has any resources, I'd sure love to see them perhaps as a separate 2D OpenGL thread. As for libraries, Kelvin's CocoaBlitz (http://www.variableaspect.com/experiments/CocoaBlitz/) looks very promising, but I haven't experimented with it much, since it's still pretty young (by his own account). There is also the Cocoa Sprite Kit (http://www.sugarcubesoftware.com/csk/), which promises an upcoming version that supports OGL. My biggest problem is that I'm not really a programmer (I just play one on TeeVee) so when faced with sample code, I spend a lot of time examining it before comprehension kicks in -- which is why I've avoided CSK and CB in favor of the low-level tutorials on SDL, such as this one (http://cone3d.gamedev.net/cgi-bin/index.pl?page=tutorials/gfxsdl/tut6), which includes rudimentary animation, scrolling, and collision detection all in one nice little package.

-daniel

[Mars_999]

This is what I am using for my shootem up. It works for what I need it to do in 2D.


bool Weapon_Hit(float weapon_x, float weapon_y, Model *object)
{
float col_width = TEXTURE_SIZE * REDUCE_TEXTURE_AMOUNT;
float col_height = TEXTURE_SIZE * REDUCE_TEXTURE_AMOUNT;
float col_width_offset = (TEXTURE_SIZE - col_width) / 2;
float col_height_offset = (TEXTURE_SIZE - col_height) / 2;
float left1 = 0;
float left2 = 0;
float right1 = 0;
float right2 = 0;
float top1 = 0;
float top2 = 0;
float bottom1 = 0;
float bottom2 = 0;

left1 = weapon_x + col_width_offset;
left2 = object->model_x + col_width_offset;
right1 = left1 + col_width;
right2 = left2 + col_width;
top1 = weapon_y + col_height_offset;
top2 = object->model_y + col_height_offset;
bottom1 = top1 + col_height;
bottom2 = top2 + col_height;

if(bottom1 < top2)
return false;

if(top1 > bottom2)
return false;

if(right1 < left2)
return false;

if(left1 > right2)
return false;
else
{
//do stuff if hit
}

return false;
}

[macboy]

Originally posted by DCoder
(HeNe lesson 21)I believe it's NeHe ;)

Even for a MetaL programmer like me that stuff was pretty interesting to look through. :)

[DJBlufire]

I finally figured out how to work my sprite engine in OpenGL and looking back it's not hard at all. The drawing function takes 10 lines of code to do and there are only a few special OGL functions that set it all up. I'd definately recommend OpenGL for 2D stuff.

[DCoder]

Originally posted by DJBlufire
I finally figured out how to work my sprite engine in OpenGL and looking back it's not hard at all.

Cool. I assume this is for your Arbetare product?

I don't suppose you'd be interested in putting together a short tutorial? I don't think I'd really need it any more, but in general, I think there's a desperate lack of 2D info out there for beginner OpenGL developers. I am planning on doing one or more myself as I move into that arena -- mainly to solidify my understanding.

-daniel

[DJBlufire]

Originally posted by DCoder
Cool. I assume this is for your Arbetare product?

I don't suppose you'd be interested in putting together a short tutorial? I don't think I'd really need it any more, but in general, I think there's a desperate lack of 2D info out there for beginner OpenGL developers. I am planning on doing one or more myself as I move into that arena -- mainly to solidify my understanding.

-daniel

This isn't for Arbetare, I'm working on this as part of a final project for my programming class.

I think I could put together a tutorial, just give me some time. I really wish there had been one when I started to research this stuff :)

[joephish]

Woohoo! yes, plleeeeease make that tutorial :-) Would be a god-send!

[DJBlufire]

OK :)

Just let me finish the project and work out all the kinks... then I know that my technique works and I could use it as an example in the tutorial.

[aaronsullivan]

As mentioned earlier, OpenGL 2D engines can have a blurry or "soft" look to them, but it seems to be avoidable.

If you are NOT using Ortho projection then there are two things you need to do to keep pixel perfect imagery.

Without Ortho
One you need to keep your imagery at an exact Z distance.
With the perspective set up like so:
gluPerspective( 45.0f, ratio, 0.1f, 1000.0f );
with an 800x600 resolution the z distance to draw your textured quad would be -90.24.

Yes, that's an odd number, but you can find them by setting up a simple testing program that allows you to move a quad forward and back until it looks pixel perfect, then just record the number.

Two, you need to offset your quad by a tiny amount. I found this on an obscure web page through a google search. Basically, you offset by 0.375. Something like this:
glTranslatef(destX+0.375,-destY+0.375,destZ);

And yes, this feels a bit hackish, but it seems to work. :rolleyes:

Another way of dealing with this is to make a texture with a resolution HIGHER than you want it to look in the final game. That way you don't get pixel perfection (and you have to guess a bit with sizes and things) but it won't look "soft."

You may wonder why you'd even WANT to do 2D without Ortho. Basically, it's for adding a 3-D twist to your graphics, like flipping, shrinking, enlarging... lighting effects.

With Ortho:
At least on my system, Ortho only works correctly up to 300 pixels over and 200 pixels down. After that everything gets that soft look.

In other words, you place your quad in the upper left hand corner of the screen and it's crisp and perfect. As soon as you move to the lower right hand side. You end up with the blurry soft look. This feels like something is broken in OpenGL or its implementation on my card... BUT Quartz Extreme works perfectly on my comp, so...

The solution?
if (destX > 300)
{
glTranslatef(0.05, 0.0, 0.0);
}

if (destY > 200)
{
glTranslatef(0.0,-0.05, 0.0);
}

Yes, it seems goofy :wacko: and like some sort of hack, but guess what? It works perfectly. Btw, this works in ANY of the common resolutions. Odd, eh?

Now, I know this all sounds like voodoo, and I personally hate these solutions. If someone has some insight into this, and a better way to handle it all, I'm VERY interested. :wow:

It's been awhile since I looked at this code, and I'm just getting back into it, so please excuse any wierdness. :?:

One thing that might make your mileage vary is that I am using large textures with all of my animation frames in a grid. When I draw the quad I use just the portion of the texture that is the current frame. I don't remember if I confirmed that this blurry soft look happens even when you use the ENTIRE texture for your quad.

[aaronsullivan]

I just wanted to mention that if you are making a 2D game and considering using OpenGL, I would also suggest using SDL (http://www.libsdl.org/index.php).

SDL is a framework that is LGPL'd. So, you'd have to give a link to a site that has the latest version to download and include a readme citing the frameworks you've used, but that's about it. You are completely free to use it for commercial products without any obligations other than those I just mentioned.

Anyway, for a game that won't be using the system GUI, SDL and OpenGL is all you need.

The big payoff is that both are cross platform. So, you can develop on your Mac, release on the Mac first, then once you get a following, release on the PC and Linux (and several other platforms) with VERY little effort.

If you haven't looked into SDL, I'd recommend it. There are several Mac developers that contribute to the code. It is extremely cross platform friendly, and the mail list is constantly active.

If you like, it can handle event grabbing, joystick support, mouse support, threads, sound... and it's all cross platform.

You don't NEED to use OpenGL with it, either, that just seems to be the way to get optimal performance now a days.

So, Check it out. (http://www.libsdl.org/index.php)

[kelvin]

ok, just to answer the big blurry 2D opengl thing:
In CocoaBlitz I use
gluOrtho2D(0, THE_VIEW_WIDTH, 0, THE_VIEW_HEIGHT);
to make all my pixels sharp.

OpenGL is faster _by far_ over quartz or QD, especially for large full screen graphics and when drawing transformed sprites.

I'm glad people are considering CB a viable option; the more feedback I get, the better I can make CB. I've looked at CSKs openGL implementation, and Vinay's on the right track if you're looking to rebuild stuff you've already made with CSK. However, he's still a ways off before a public release.

I'll try to make some more demos for CB as soon as I can. If anybody wants to help, I'll host demos on variableaspect or link.

[mkeC]

I just want to say that I was avoiding OpenGL like the plauge.
I'm just learning Cocoa, I don't know C or C++, and just spend a week figuring out NSImage.

But when I downloaded CocoaBlitz all of my problems were instantly solved. It took a bit to understand how "cells" were being used as sprites. But after a couple hours I'd say its pretty intuitive. Some documentation would be nice but if you stare at the code in the CBWindowDemo and the header files you can quickly figure out what is going on.

I'd say there is NOT much reason to use plain old Quartz if your starting from scatch. When CSK gets OpenGL that will be even more reason to abandon plain old Quartz for sprite animation. I'll admit that my Quartz code was a feeble hack but the speed increase is truly breathtaking.

OK I'll settle down now...

-Mike

[arekkusu]

Originally posted by aaronsullivan
In other words, you place your quad in the upper left hand corner of the screen and it's crisp and perfect. As soon as you move to the lower right hand side. You end up with the blurry soft look. This feels like something is broken in OpenGL or its implementation on my card... BUT Quartz Extreme works perfectly on my comp, so...


I have the same problem. And BTW the redbook spec with .375 or .5 offsets is only for lines and points. Not triangle/quad geometry.

The bad thing about this is that, although Quartz Extreme aligns perfectly, Apple's sample GL code (OpenGL Image, or other examples that use Ortho2D) have the same problem.

I think it's a bug in GL. I've submitted a bug to RADAR about it. You can see examples of the problem and a test app at http://homepage.mac.com/arekkusu/bugs/gluOrtho2D_inexact.html

[arekkusu]

Originally posted by mkeC
I'd say there is NOT much reason to use plain old Quartz if your starting from scatch... I'll admit that my Quartz code was a feeble hack but the speed increase is truly breathtaking.


I agree. I converted my fractal drawing app from Quartz to GL last week. It draws around 45k antialiased lines. The speed improvement was over 100x. A set that takes 8 seconds to draw inQuartz takes 0.06 seconds in GL.

Yes, I know about NSBezier path intersection problems. And I was using CG directly, with small segment lengths.

Quartz is just terribly slow. Hopefully it'll be optimized more in Panther.

[CobraMantis]

Humm...
Well, I've been wanting to learn OpenGL for quite some time now, but have never really gotten around to doing so. The game I'm working on currently is using QuickDraw. Reading through this thread has made me wonder whether I should switch to OpenGL instead.

I currently have zero experience with OpenGL. How hard would it be to learn enough about it to be able to use it for a fairly simple 2D game? You guys have mentioned that it's a good deal faster than Quartz for 2D games, so I assume it would also be much faster than QD?

Thanks!

[Josh]

OpenGL is the fastest way to draw to the screen. Quartz and QuickDraw get left in the dust. :cool:

[OneSadCookie]

Learning how to use OpenGL for 2D would not be difficult (particularly not for someone who can understand CopyBits ;)).

There are a number of people on this forum who've made the leap recently, and there was some talk of making a tutorial. Perhaps someone in that boat could step up here?

[Patrick]

On older macines without graphics acceleration, QuickDraw will blow away OpenGL - I've noticed that software opengl has a terrible rendering speed. Some people still use iMacs/old powerbooks and the Rage IIc/Rage LT Pro chips in them don't support GL well AFAIK.

If your game doesn't need fancy GL effects, I'd think it would be better to go with QuickDraw for maximum compatibility. Just my two cents.

[kelvin]

Originally posted by Patrick
On older macines without graphics acceleration, QuickDraw will blow away OpenGL - I've noticed that software opengl has a terrible rendering speed. Some people still use iMacs/old powerbooks and the Rage IIc/Rage LT Pro chips in them don't support GL well AFAIK.

If your game doesn't need fancy GL effects, I'd think it would be better to go with QuickDraw for maximum compatibility. Just my two cents.

I dunno, I consider both of my systems old:
450Mhz PowerMac G3 B&W (16MB rage128)
500Mhz PowerBook G3 firewire (8MB agp rage128)
and OpenGL runs fine.

I can't imagine getting anything done with older systems, just getting around in Mac OS X would be slow, never mind gaming.

[mars]

Regarding the blurry look of many games, notwithstanding the issues regarding texture coordinates and an apparent rendering bug, keep in mind the following simple but oft unregarded fact:

if you are playing on an LCD screen, and you (or the application) chooses a non-native resolution, then the resulting screen image will be interpolated. This is really bad news for image quality.

For example, if you you are playing game X on your new iBook 14", at the native resolution of 1024x768, but you choose a fullscreen game mode of 800x600 (or, god forbid, 640x480) for reasons of speed, then the image is going to look absolutely lousy.

This isn't really an issue with OpenGL, at least not in this instance, but with the hardware and what the OS can do with it.

Switch to windowed mode (if possible) and hey presto, the game suddenly becomes sharp and clear (assuming of course, that you are running in a native resolution for your display device). Obviously, this is not always desirable but it does show that OpenGL can render sharp, pixel-perfect graphics.

Of course, if a game consists almost entirely of tiny textures overstretched on large polys, that doesn't help the overall aesthetic either. ;)

[Josh]

Originally posted by Patrick
On older macines without graphics acceleration, QuickDraw will blow away OpenGL - I've noticed that software opengl has a terrible rendering speed. Some people still use iMacs/old powerbooks and the Rage IIc/Rage LT Pro chips in them don't support GL well AFAIK.I have a beige G3 with a Rage IIc running Mac OS X and OpenGL is still faster than QuickDraw.

[Patrick]

I guess it's just on Wallstreet and Lombard Powerbooks then, that OpenGL would be slower ( those machines have no graphics acceleration under OS X )

I thought I had read that the Rage IIc only supported RAVE, but perhaps OS X or one of the Classic iterations added opengl support.

[Josh]

It doesn't have accelerated OpenGL, but it can still do OpenGL. I'm suprised QD is slower on your Wall Street...

[aaronsullivan]

Originally posted by kelvin
[B]ok, just to answer the big blurry 2D opengl thing:
In CocoaBlitz I use
gluOrtho2D(0, THE_VIEW_WIDTH, 0, THE_VIEW_HEIGHT);
to make all my pixels sharp.

I've noticed that CB doesn't seem to have the blurry/soft look but I haven't been able to verify that gluOrtho2D is THAT different from glOrtho2D.

In my programs (which are currently broken due to some change in OSX/SDL I haven't had time to figure out yet) I use glOrtho2D with the extra z range numbers. Are you saying that using gluOrtho2D makes the difference? I really wish my code was compiling right now because it would take 2 seconds to confirm on my own! :sneaky:

Is it possible that using Cocoa has anything to do with it? (Seems unlikely, because it's using OpenGL the same way :p )

Anyway, if anyone can confirm for me that using glOrtho2D instead of gluOrtho2D is what causes the bug, I would be very grateful. :love:

Also, I'd like to see that tutorial someone mentioned they were working on. :) Mostly, I'm curious to see if any of these little problems pop up. Is that still in the works? :)

Aaron

[skyhawk]

could it just be that people are using 0,640,0,480 instead of 0,639,479 like they SHOULD be using :rolleyes: None of my games have suffered from "soft pixel" look" check out SitS in another thread, my tile engine is sharp, crisp and smooth

[arekkusu]

Originally posted by skyhawk
could it just be that people are using 0,640,0,480 instead of 0,639,479 like they SHOULD be using :rolleyes: None of my games have suffered from "soft pixel" look" check out SitS in another thread, my tile engine is sharp, crisp and smooth

This is wrong, check the redbook spec (appendix H):


If exact two-dimensional rasterization is desired, you must carefully specify both the orthographic projection and the vertices of primitives that are to be rasterized. The orthographic projection should be specified with integer coordinates, as shown in the following example:
gluOrtho2D(0, width, 0, height);

I bet that you simply aren't noticing that your pixels are slightly off. Try using a black and white checkerboard and zooming in with Pixie.

I invite you to download the sample I gave Apple, at
http://homepage.mac.com/arekkusu/bugs/gluOrtho2D_inexact.html
and see if you can get it to display perfectly sharp. None of Apple's sample code can do it.

[skyhawk]

0-512 is 513 pixels.... count them if you must.

Here is what I did:
I made a 800x600 window
I made a ortho view in it 0,799,0,599
I drew in it.


My view is COMPLETELY crisp.

[arekkusu]

Originally posted by skyhawk
My view is COMPLETELY crisp.

(downloads SitS007)

Well, yep, it looks crisp. But I wonder if you've got linear filtering turned on. And I bet you draw each tile into the viewport separately. What happens if you draw them all to an offscreen context, and then use that context as one big rectangle texture?

To see what I mean, download "TileScroller 02-15-2003.dmg" from
http://homepage.mac.com/arekkusu/FileSharing1.html

Turn off the block filtering and lighting (f, l). Now, it looks sharp at first glance but take a close look at the bottom right corner with pixie. It's smudged.

The problem is worse when you use linear filtering and large rectangle textures. Apple has no fix yet.

[skyhawk]

>>Well, yep, it looks crisp. But I wonder if you've got linear filtering turned on.
no
>> And I bet you draw each tile into the viewport separately.
you mean I draw my quads on the screen? yes, since everything is double buffered in OS X, why would I want triple buffering? a friggin waste of speed. All my quads are drawn in 1 for loop... 1... bada bing bada boom K.I.S.S. :)

>>What happens if you draw them all to an offscreen context, and then use that context as one big rectangle texture?
if you use the proper coordinates and stuff LIKE I TOLD YOU, then everything would look fine

>>To see what I mean, download "TileScroller 02-15-2003.dmg" from
http://homepage.mac.com/arekkusu/FileSharing1.html
Didn't run, Whined about no rectangle texture. Sorry, but that gets a pathetic in my book. :mad:

>>Turn off the block filtering and lighting (f, l). Now, it looks sharp at first glance but take a close look at the bottom right corner with pixie. It's smudged.
then stop doing it your way and do it mine?

>>Apple has no fix yet.
I don't believe apple is the problem

[aaronsullivan]

Originally posted by skyhawk
0-512 is 513 pixels.... count them if you must.

Here is what I did:
I made a 800x600 window
I made a ortho view in it 0,799,0,599
I drew in it.


My view is COMPLETELY crisp.

If that is all it takes, then :blush: ! It does make a good amount of sense that it would cause the exact problem we are having. As much as I'd feel stupid I really don't care as long as it works!

Arekkusu did you try using the 0 to max-1 as opposed to 1 to max?
Please confirm this. It's killing me that I can't compile right now. I'll just have to dig back in to my code. :sneaky:

BTW, having 100's of rotating, scaling, transparent, animating sprites at way over 60 fps is really nice. You can't do that without OpenGL on the Mac as far as I know.

Also It should be stated that another thread has been started about Allegro, another cross platform API (besides SDL) that is a 2D engine just being converted to OS X. :cool: That's a lot more on topic than the rest of the discussion going on in this thread. :sneaky: :rolleyes:

Should we start a new thread about making OpenGL work as a 2D engine? :shock: Or should we keep all this information locked away where no one will see it? :ninja:

Aaron

[skyhawk]

>>BTW, having 100's of rotating, scaling, transparent, animating sprites at way over 60 fps is really nice. You can't do that without OpenGL on the Mac as far as I know.

EV Nova does it, but they do dirty rectangles and that is a complicated procedure

[arekkusu]

Originally posted by skyhawk
>>I wonder if you've got linear filtering turned on.
no
>> And I bet you draw each tile into the viewport separately.
why would I want triple buffering?

Perhaps your application doesn't need it. But more complex games might want to:

* Scale, rotate, shear, distort playfield elements or sprites. You want filtering for this.
* Reuse rendered playfield elements multiple times in once frame for effects. Heatwave, mirrors, feedback, etc. You need to render offscreen to do this (not quite the same as triple buffering.)

if you use the proper coordinates and stuff LIKE I TOLD YOU, then everything would look fine

Actually, it still doesn't.

Didn't run, Whined about no rectangle texture. Sorry, but that gets a pathetic in my book. :mad:

Ah. Well, perhaps try again when you get a new Mac capable of Quartz Extreme.


Originally posted by aaronsullivan
Arekkusu did you try using the 0 to max-1 as opposed to 1 to max?

Yes, I investigated this quite heavily six months ago including asking Geoff Stahl about it. The bug is still open.

[skyhawk]

well at least fix your "bug" page so it looks like you know what you are doing, your bug page clearly shows that you are sticking a 512 pixel sprite into 513 pixels

as for motion blurring and needing to write to a "third buffer", it would not cause this problem.

So far, if you claims this problem exist even after I told you to fix the coordinates then.

1) this problem is unique to you and a few others who are doing exactly what you are doing wrong

2) I recommend you change what you are doing. cause goshdamnit, I'm not going to rewrite your engine to show you how to fix it. Way too much work.

>>Ah. Well, perhaps try again when you get a new Mac capable of Quartz Extreme.

End of summer. and what is so advanced about this game that it requires such a high end mac? :shock:

[arekkusu]

Originally posted by skyhawk
well at least fix your "bug" page so it looks like you know what you are doing, your bug page clearly shows that you are sticking a 512 pixel sprite into 513 pixels

Actually, no. The glOrtho clipping planes don't work like that. If you look around you'll see it's correct to use the full width/height:

OpenGL FAQ on opengl.org:
gluOrtho2D (0, windowWidth, 0, windowHeight);

Apple's BoingX:
glOrtho(0,[self bounds].size.width,0,[self bounds].size.height, 0.0f, 2000.0);

Apple's CGImage Loader:
gluOrtho2D(0.0f, size.width, 0.0, size.height);

Apple's GLChildWindowDemo:
glOrtho(0,bounds.size.width,0,bounds.size.height,-1,1);

Apple's Stencil Shadows:
gluOrtho2D(0.0f, size.width, size.height, 0.0f);

NeHe lesson #21:
glOrtho(0.0f,width,height,0.0f,-1.0f,1.0f);

etc.

I suggest that you turn filtering on in your code, and then see how well things line up for you.

and what is so advanced about this game that it requires such a high end mac? :shock:

I consider a Radeon/GF2 as a bare minimum. NPOT textures are essential when you need a lot of arbitrarily shaped offscreen texture contexts.

[aaronsullivan]

Originally posted by skyhawk
>>BTW, having 100's of rotating, scaling, transparent, animating sprites at way over 60 fps is really nice. You can't do that without OpenGL on the Mac as far as I know.

EV Nova does it, but they do dirty rectangles and that is a complicated procedure

EV Nova has hundred's of sprites on screen? As in OVER 200 sprites? That scale? I know it has some transparency and it also uses pre-rendered animations to simulate rotation... but that's not true rotation and the sprites don't scale at all.

EV Nova uses a modified version of SpriteWorld, which has since been updated to use OpenGL for hardware acceleration.

Obviously, the game is still great. :cool:

I've never implemented dirty rectangles at a low level, but it's actually not TOO complicated. You just widen a rectangle to include any changed spots on the screen and update only that part in the buffer. (Or use multiple rectangles.) SpriteWorld does this for you "for free."

I like SpriteWorld but, Anders who did all the recent work with it has frustrating opinions about dealing with OS X. He doesn't like the fact that the API's are changing, and complains about buying new versions of the OS, but also doesn't consistantly support the FREE Project Builder, instead only making sure the expensive CodeWarrior projects work. BUT DON'T GET ME WRONG, he did incredible work on it, all for free. :D

Anyway, SpriteWorld was great when I was using it, and Anders has passed the torch on to someone (Ken) JUST before it came out of beta. It's been a long wait and I moved on as it isn't currently cross platform. :(

If you're interested in SpriteWorld check out the site. (http://www.spriteworld.org/) To find out the most recent info and where to get the latest version 3.0b2 check out the mailing list and just look at the archives.

Btw, let's keep it a bit more civil. No need to argue, just to figure this all out together. ;)

Aaron

P.S. I dig the icon with the Ultima dude from the Apple ][ version :cool:

[aaronsullivan]

Originally posted by arekkusu
Actually, no. The glOrtho clipping planes don't work like that. If you look around you'll see it's correct to use the full width/height:

OpenGL FAQ on opengl.org:
gluOrtho2D (0, windowWidth, 0, windowHeight);

Apple's BoingX:
glOrtho(0,[self bounds].size.width,0,[self bounds].size.height, 0.0f, 2000.0);
etc. etc.

Just wanted to point out that you are using examples from Apple code that you said DOESN'T look correct anyway. So... they are poor examples of how it "should" be done. :ohmy:

I'm still curious if either of you have tried the other persons' tests.

I'd be doing all the testing myself except: My Project Builder code is building everything fine and then gives me a nice big green checkmark next to the phrase BUILD FAILED. I check the "tree" using the contextual menu and I get a failure to create an object or something... I could use a hint on where that's coming from, since I haven't changed the actual code at all. I'll do a more specific post about it if I can't figure it out, but if it sounds familiar I'd love to hear about it.

Aaron

[Tycho]

I consider a Radeon/GF2 as a bare minimum. NPOT textures are essential when you need a lot of arbitrarily shaped offscreen texture contexts.

All I can say is that if you're going to release a 2D game with requirements as high as Doom 3, it had better be one hell of a good 2D game.:p

[aaronsullivan]

By the time I get my game done, you'll be able to pick up these video cards for $20. ;)

[aaronsullivan]

btw, a similar discussion just started up on the Apple OpenGL list

>> glViewport(0, 0, w, h);
>> glMatrixMode(GL_PROJECTION);
>> glLoadIdentity();
>> glOrtho(0, w, h, 0, -1, 1);
>
> You probably want that to be (0, w-1, h-1, 0, -1, 1). It takes
> left/right, ..., not left/width.

No, the original version is correct. OpenGL's coordinate system just
just like the lines on graph paper, with pixel centers in the middle of
the squares. So if you were to draw a box surrounding the same number
of pixels as your window size, you can see that you'd want 0,w,h,0 in
his case.

Aaron

P.S. Am I allowed to do that? I'll have to check the list guidelines again. :ohmy:
P.P.S. It's customary to give a link to the lists where it came from:Apple Lists (http://lists.apple.com/)

[arekkusu]

Originally posted by Tycho
All I can say is that if you're going to release a 2D game with requirements as high as Doom 3, it had better be one hell of a good 2D game.:p

Well, Doom 3, and I predict more and more 3D games after that, will be requiring vertex and pixel shaders to get the best visuals. That means Geforce 3 or Radeon 8500 or newer. And really, Geforce FX or Radeon 9700 for the real floating point pixel shaders.

A Radeon or Geforce 2 is already quite a low minimum requirement. Apple has the same requirements for Quartz Extreme, I don't think it's too much to ask for. Sorry if you feel otherwise.

[skyhawk]

it really ISN'T too much to ask for, but never whine about getting a smaller slice of an already small slice of pie.

[aaronsullivan]

Guys, I posted a new thread asking a related question. I'm interested in your answer. Please, check it out here. (http://www.idevgames.com/forum/showthread.php?s=&threadid=3793)
Thanks! :)

P.S. I'm compiling again after a devTools and SDL reinstall... so maybe I'll have something a little more concrete to contribute now.

[aaronsullivan]

So...

Just using gluOrtho2D... well, that was an answer to the "big" blurry question. In other words, since the imagery matches the resolution, it shouldn't be scaled and aliased. That answered Carl's larger question, but there is another.

The more difficult problem is the slight pixel shifting that gives a soft look near the bottom right hand side of the screen.

Skyhawk's proposed solution:
gluOrtho2D(0,width-1,0,height-1);
In my program, I tried subtracting 1 from my width and height values (starting at 0) and it made the effect even worse.

Why does it work for his program? Well, I tried what arekkusu suggested in my program, (after removing my hack) and, indeed, turning on GL_Nearest filtering fixed everything. Except, that scaling or rotating would look awful! :) I'm assuming that, if Skyhawk turned on GL_Linear filtering in his program, he'd see the same ugliness in the corner of his window.

So, where does that leave us? It leaves us waiting for a bug fix. In the mean time, I'm using my old hack, which, as said before, works:
if (destX > 300)
{
glTranslatef(0.05, 0.0, 0.0);
}

if (destY > 200)
{
glTranslatef(0.0,-0.05, 0.0);
}

The only problem with this, is that if Apple fixes the bug, the hack may CAUSE the effect it's supposed to fix... but I'm guessing it won't, since the offset is so small.

Aaron
P.S. sorry for the duplicate posts that were here!:blush:

[arekkusu]

Originally posted by aaronsullivan
So...
The more difficult problem is the slight pixel shifting that gives a soft look near the bottom right hand side of the screen.

This problem is very slight. It is most obvious when you use high-contrast images, and one large quad. It also has slightly different behavior between 2D and rectangle textures, and between ATI and nvidia hardware.

As you point out, turning off filtering is one way to reduce (but not completely eliminate) the problem. But you might require filtering to be on depending what you're doing.

Geoff Stahl at Apple recently implied an upcoming fix for this problem, so my advice is to just ignore it for now. Any tweaks you make could well break on future systems.

Here's the (somewhat oddly worded) comment from him, re: RADAR 3144695:


This bug is now in verify to be fixed in a future OS release/update. I just verified the bug fixed the other day myself. Obviously I can't comment on where/how this fix will be released.

[aaronsullivan]

Thanks to someone trying to put SpriteWorld on top of SDL, SpriteWorld may become a crossplatform library. That's pretty cool.

If you're interested, you can read about it here:
http://www.pairlist.net/pipermail/swml/2003/date.html#2058

Also, the main site is:
www.spriteworld.org

[arekkusu]

Oops, I didn't see these other comments...

Originally posted by aaronsullivan
etc. etc.
Just wanted to point out that you are using examples from Apple code that you said DOESN'T look correct anyway. So... they are poor examples of how it "should" be done. :ohmy:

I'm still curious if either of you have tried the other persons' tests.

That's true, the "correct" way to do it doesn't work. But that doesn't make an incorrect way any better. ;)

I've tried many many incorrect ways. It's really a bug in GL. Hopefully fixed in 10.2.7, if not, 10.3.

P.S. I dig the icon with the Ultima dude from the Apple ][ version :cool:

Thanks. That's from Untima 9 (http://homepage.mac.com/arekkusu/SW/).

[aaronsullivan]

Honestly, I'm just glad to know what was going on. I fixed it, but I was never satisfied with it. :mad:

All is :cool: now.