Madbomber for PDAs :)

It seems John Hall’s been working on SDL for iPAQ/Zaurus, so I’m
already getting one of my games ready for it >:^)

http://www.sonic.net/~nbs/madbomber-sideways.gif

John - how’s it goin’, eh? :wink:

-bill!

It seems John Hall’s been working on SDL for iPAQ/Zaurus, so I’m
already getting one of my games ready for it >:^)
http://www.sonic.net/~nbs/madbomber-sideways.gif

Woohoo! SDL is in a great position to become a predominant platform
for PDA game development. It’s thin, flexible, fast, and testable on
the desktop. Let’s make it happen.

John - how’s it goin’, eh? :wink:

Due to some Palm OS related nightmares last weekend, I had almost no
time to work on SDL. I did rip out some of my iPAQ-specific changes
to make way for a more general PDA configuration option. I intend to
reimplement the framebuffer driver with screen rotation support and
a small amount of ARM assembly for blitting. The framework is in place
(thanks largely to Icculus’ null driver), and I hope to have something
displaying in a week or two (depending on school work and a contract
Palm job).

Why a new FB driver? The current driver is made to support a wide
variety of framebuffer devices, and it works pretty well for the most
part. However, these PDA’s have several interesting properties:

-They are almost always 320x240, 16-bit. The iPAQ uses a 4-4-4 RGB
packing, with 4 unused bits per pixel. The Zaurus, I believe, uses
a 5-6-5 packing. In any cases, these displays are almost always 16-bit.
We can optimize for this.

-Screen rotation is basically a requirement. It is cumbersome to play
games sideways, and silly to force game programmers to support rotation
themselves.

-PDA’s have special input requirements, and definitely do not low-level
protocol support for PS/2 wheel mice.

-Virtual console switching needs to be handled differently on PDA’s.
I’m not sure exactly how it should be done, but the current system
is broken.

-Hardware surfaces have no meaning on this type of display controller.
Nor do mode switching or page flipping, but SDL’s current FB driver
seems to think they are supported, and tries to set invalid modes.
This causes screen corruption.

I think we can build a much faster and simpler PDA-specific framebuffer
driver if we get rid of these and other various pieces of PC-related
cruft in the current FB driver. The new driver will be a configure option
that defaults to ‘off’.

Thoughts?

-JohnOn Mon, Jan 28, 2002 at 05:06:45PM -0800, nbs wrote:


John R. Hall - Resident, Sol System, 3rd Planet Out
Student, Georgia Tech; Author, Programming Linux Games

-They are almost always 320x240, 16-bit. The iPAQ uses a 4-4-4 RGB
packing, with 4 unused bits per pixel. The Zaurus, I believe, uses
a 5-6-5 packing. In any cases, these displays are almost always 16-bit.
We can optimize for this.

It’s probably naive to believe this will be true for very long…do you
think it’s unlikely that the next generation of PDAs are going to be
24-bit color?

I also wouldn’t be surprised to find higher resolutions in the same screen
dimensions.

In short, be careful what you optimize for.

–ryan.

I hope to have something displaying in a week or two

John, you wouldn’t happen to be putting your code public somewhere
would you? I’d be willing to help test/debug…

I think we can build a much faster and simpler PDA-specific framebuffer
driver if we get rid of these and other various pieces of PC-related
cruft in the current FB driver. The new driver will be a configure option
that defaults to ‘off’.

The biggest issue here is that the optimizations require almost
a per device code. As such the build tree should probably reflect this. :slight_smile:

I’d be more than willing to help test and debug, I’ve got a Zaurus and
and iPaq, all I need is some code. (which I’d offer to help write but
I’m already writing more than 1000 lines of code per night after writing
code at work all day…)On Tue, Jan 29, 2002 at 12:10:41AM -0500, John R. Hall wrote:


David J. Goehrig dave at cthulhu-burger.org

All reports, excluding those of historical fact, may be considered speculative.
- a faceless Compaq disclaimer

I hope to have something displaying in a week or two

John, you wouldn’t happen to be putting your code public somewhere
would you? I’d be willing to help test/debug…

Not currently; there’s really nothing to show, just some autoconf updates
and a partly working patch to the old FB driver. I’ll make the code
available as soon as it’s usable.

I think we can build a much faster and simpler PDA-specific framebuffer
driver if we get rid of these and other various pieces of PC-related
cruft in the current FB driver. The new driver will be a configure option
that defaults to ‘off’.

The biggest issue here is that the optimizations require almost
a per device code. As such the build tree should probably reflect this. :slight_smile:

Agreed. I’m targetting the iPAQ and the Zaurus with this driver.

Icculus: yes, PDA screens will grow beyond 320x240x16bit, but for the
forseeable future they’ll use basically the same type of embedded display
controller, and most of my listed points for rewriting the driver will hold.
We’ll still need the ability to rotate the screen, deal with a severely
limited range of supported display modes, and handle PDA-specific forms
of input.

I’d be more than willing to help test and debug, I’ve got a Zaurus and
and iPaq, all I need is some code. (which I’d offer to help write but
I’m already writing more than 1000 lines of code per night after writing
code at work all day…)

Cool, expect something to test in the next few weeks.

-JohnOn Tue, Jan 29, 2002 at 03:25:26AM -0600, Dave Goehrig wrote:

On Tue, Jan 29, 2002 at 12:10:41AM -0500, John R. Hall wrote:


John R. Hall - Resident, Sol System, 3rd Planet Out
Student, Georgia Tech; Author, Programming Linux Games

[…]

-Screen rotation is basically a requirement. It is cumbersome to play
games sideways, and silly to force game programmers to support rotation
themselves.

How about rotating the textures (of display format surfaces) and
coordinate system internally? Would eliminate all actual rendering
overhead, although I don’t know how hard it would be to hide that inside
an SDL rendering backend. (It mustn’t surface to the API level, as SDL
doesn’t have a way of describing “vertical run” surfaces…!)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 29 January 2002 06:10, John R. Hall wrote:

-They are almost always 320x240, 16-bit. The iPAQ uses a 4-4-4 RGB
packing, with 4 unused bits per pixel. The Zaurus, I believe, uses
a 5-6-5 packing. In any cases, these displays are almost always
16-bit. We can optimize for this.

It’s probably naive to believe this will be true for very long…do you
think it’s unlikely that the next generation of PDAs are going to be
24-bit color?

Well, lots of laptops - even the one with big, nice screens - seem to
make use of only 18 bits, but 24 bit modes are still interesting,
especially for software rendering. (Then again, how long until we see the
first ultra low power version of a portable 3D accelerator chip in a PDA?)

I also wouldn’t be surprised to find higher resolutions in the same
screen dimensions.

Likely. 320x240 isn’t much even in that size. (What do fonts look like,
actually? Does it even make senes to use antialiazing?)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 29 January 2002 09:57, Ryan C. Gordon wrote:

Many of the fonts used on the Zaurus (esp. under Opera browser) are
anti-aliased. It does help, actually. :slight_smile:

(Wishing the terminal’s “tiny” font, which isn’t antialiased, either
(1) was, or (2) wasn’t so square looking)

-bill!On Wed, Jan 30, 2002 at 11:07:21PM +0100, David Olofson wrote:

Likely. 320x240 isn’t much even in that size. (What do fonts look like,
actually? Does it even make senes to use antialiazing?)

Likely. 320x240 isn’t much even in that size. (What do fonts look like,
actually? Does it even make senes to use antialiazing?)

Actually, antialiasing is more important at low resolutions - remember that
it’s there to make things look better. No serious C64 graphics works are done
without it =) … You have to be careful to not overdo it, though.–
Trick


Linux User #229006 * http://counter.li.org

“There is no magic” - Nakor, magic user

Yeah, that’s true in many cases - but the unsharpness side effect that AA
generates fonts in low resolutions may be hard on the eyes for long
session.

IMHO, in programming editors and the like, AA shouldn’t be used unless
you have high enough resolution that the fonts only appear “cleaner”,
with no visible blurring.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 31 January 2002 19:49, Trick wrote:

Likely. 320x240 isn’t much even in that size. (What do fonts look
like, actually? Does it even make senes to use antialiazing?)

Actually, antialiasing is more important at low resolutions - remember
that it’s there to make things look better. No serious C64 graphics
works are done without it =) … You have to be careful to not overdo
it, though.