GP2X Writing A Comic Book Reader...


Blackaxis

Still Fresh
Joined
Nov 22, 2005
Messages
12
Website
Visit site
First let me say that I'm a not a good programmer, in fact, I'm a pretty big newbie. I don't own a gp2x yet, but I've been writing the building blocks of a comic book reader (zip or rar archives containing large jpegs) using SDL. The problem is that the images are pretty big, right now on my linux box, the sprogram takes about 20megs of memory while running with just one page loaded into memory along with it's scaled counterpart that's written to the screen. I would like to be able to have at least more than one page loaded into memory to allow fast page flips.

How much free memory am I able to play with while the gp2x runs linux? Has anyone done this before and can offer tips?
 
First let me say that I'm a not a good programmer, in fact, I'm a pretty big newbie. I don't own a gp2x yet, but I've been writing the building blocks of a comic book reader (zip or rar archives containing large jpegs) using SDL. The problem is that the images are pretty big, right now on my linux box, the sprogram takes about 20megs of memory while running with just one page loaded into memory along with it's scaled counterpart that's written to the screen. I would like to be able to have at least more than one page loaded into memory to allow fast page flips.

How much free memory am I able to play with while the gp2x runs linux? Has anyone done this before and can offer tips?
20 Megs - holy crud Batman! I would suggest doing an SDL_FreeSurface of the original image just after you convert it for displaying, after it's on the screen you have no need for the original and it's just taking up (loads of) space.
 
Last edited by a moderator:
Use 16 bit surfaces you will halve your memory usage.

I concur, I think the 16 bit surfaces won't really have any noticable difference especially on a handheld LCD and as mentioned the memory usage will be halved.

Additionally, this is exactly the sort of program I've been waiting for. It's a great idea! :)
 
Last edited by a moderator:
First let me say that I'm a not a good programmer, in fact, I'm a pretty big newbie. I don't own a gp2x yet, but I've been writing the building blocks of a comic book reader (zip or rar archives containing large jpegs) using SDL. The problem is that the images are pretty big, right now on my linux box, the sprogram takes about 20megs of memory while running with just one page loaded into memory along with it's scaled counterpart that's written to the screen. I would like to be able to have at least more than one page loaded into memory to allow fast page flips.

How much free memory am I able to play with while the gp2x runs linux? Has anyone done this before and can offer tips?
20 Megs - holy crud Batman! I would suggest doing an SDL_FreeSurface of the original image just after you convert it for displaying, after it's on the screen you have no need for the original and it's just taking up (loads of) space.

My original plan for the reader was let the user zoom in and out quickly for better viewing, that's why I kept the original image in memory. But, by changing the depth to 16 and freeing the original image after each scaling, I got it to be between 9 and 14 megs, depending on the scale.
 
Last edited by a moderator:
I would recommed you allow rotaion. As most comic pages are portrait.

Good luck!



You mean like this? That's not hard at all, there is a combination rotate and zoom function in SDL_gfx.

Off-topic: Blackaxis, can you fill me in on how you got Anjuta set up to use the SDL libs? I can't find any good how-tos and the FAQ on the Anjuta website sucks.

If you or anyone else fills me in I'll do a write up for the Wiki. :)
 
Last edited by a moderator:
Code:
              total         used         free       shared      buffers
  Mem:        30488         6496        23992            0           28
 Swap:            0            0            0
Total:        30488         6496        23992

Argh. Well, right now, it would fit, but I don't know once you start incorporating code to uncompress the cbz and cbr files (I have no idea how memory intensive they are) on the fly. It might only be possible if you "pre-decompress" the archive into the individual jpgs before hand.
 
Last edited by a moderator:
I would recommed you allow rotaion. As most comic pages are portrait.

Good luck!



You mean like this? That's not hard at all, there is a combination rotate and zoom function in SDL_gfx.

Off-topic: Blackaxis, can you fill me in on how you got Anjuta set up to use the SDL libs? I can't find any good how-tos and the FAQ on the Anjuta website sucks.

If you or anyone else fills me in I'll do a write up for the Wiki. :)


Actually, i just hand wrote a makefile and imported my "scalingtest1" directory as a project using File -> Import Project.

This is my makefile right now:

Code:
all: main

main: main.o
	gcc -lSDL -lSDL_image -lSDL_gfx -lstdc++ main.o -o main
	
main.o.: main.cc
	gcc -c `sdl-config --cflags` main.cc
 
Last edited by a moderator:
If anyone's interested, last night I got zziplib working with SDL, it's a very useful library. I was able to create list of a zip file's contents and use that to load images without decompressing the entire archive.

So now I just have to merge that with my current image scaling/rotation/displaying routines. It seems to be turning out pretty well. If you change the size of the screen it's not a bad reader for linux, although for that large of a screen I would like to to display two pages side by side.

Does anyone have any information on libraries for handling rar files?
 
Hey, Blackaxis. What a great idea this is. I was searching for some ideas on how to port CDisplay over to the GP2X, but it sounds like you got your own thing going. Awesome. Any new news?

Pariah B)
 
well, ~24mb isnt that bad, and there might be a way to get acces to additional 16mb
If you know its physical address (0x03500000?) you can easily mmap it:

Code:
#include <sys/mman.h>
void *sixteenmegs = NULL;
int memfd = open ("/dev/mem", O_RDWR);
if (memfd != -1) {
    sixteenmegs = mmap (0, 16*1024*1024, PROT_READ|PROT_WRITE, MAP_SHARED, memfd, 0x03500000);
    if (sixteenmegs == MAP_FAILED) sixteenmegs = NULL;
}

Now so long as sixteenmegs doesn't come out NULL, it points at a 16Mb block starting from physical address 0x03500000. You can subdivide the block and set up your own pointers inside it, relative to sixteenmegs.

Note that I have no idea if it makes sense to do this - I don't know anything about how the memory is apportioned in GP2X Linux - but this is how you'd gain access to a 16Mb block at the given physical address.

If you want to tidy up afterwards:

Code:
if (sixteenmegs) munmap (sixteenmegs, 16*1024*1024);
if (memfd != -1) close (memfd);
 
Last edited by a moderator:
I'm looking forward to this, that way I can pile a lot of manga on an SD for viewing pleasure wherever I go. ^_^

Zooming is a must, tho' because I don't think scaling will favor text that well.

EDIT:

Blackaxis posted on Dec 2 2005 at 12:44 PM said:
If anyone's interested, last night I got zziplib working with SDL, it's a very useful library. I was able to create list of a zip file's contents and use that to load images without decompressing the entire archive.

So now I just have to merge that with my current image scaling/rotation/displaying routines. It seems to be turning out pretty well. If you change the size of the screen it's not a bad reader for linux, although for that large of a screen I would like to to display two pages side by side.

Does anyone have any information on libraries for handling rar files?

I found this pretty quickly on Google: http://www.unrarlib.org/

Hope that helps.
 
Last edited by a moderator:
Sorry about double posting, but I just wanted to know if you were still working on this.

Also, would you be able to release a version now? It doesn't have to have Zip and RAR compression for your first version, as long as it can view image files. I would really like a viewer for my manga, and I don't want to risk updating to 1.2.0 as of yet. ;P
 

You mean like this? That's not hard at all, there is a combination rotate and zoom function in SDL_gfx.

please can you tell me how you set upped this Anjuta environment for GP2X development?

(Also) got Ubuntu Linux on my notebook and want to start devving for GP2X too. Got Anjuta installed, run build.sh script, which created /usr/local/devkitPro with lots of stuff but still can't compile basic sample proggies for SDL... am I missing SDL? How to install it and what steps to take to have environment like you.

Thanx!
 
Last edited by a moderator:

You mean like this? That's not hard at all, there is a combination rotate and zoom function in SDL_gfx.

please can you tell me how you set upped this Anjuta environment for GP2X development?

(Also) got Ubuntu Linux on my notebook and want to start devving for GP2X too. Got Anjuta installed, run build.sh script, which created /usr/local/devkitPro with lots of stuff but still can't compile basic sample proggies for SDL... am I missing SDL? How to install it and what steps to take to have environment like you.

Thanx!

You should read the WHOLE topic, BlackAxis already told Ravnos what he did here:

I would recommed you allow rotaion. As most comic pages are portrait.

Good luck!



You mean like this? That's not hard at all, there is a combination rotate and zoom function in SDL_gfx.

Off-topic: Blackaxis, can you fill me in on how you got Anjuta set up to use the SDL libs? I can't find any good how-tos and the FAQ on the Anjuta website sucks.

If you or anyone else fills me in I'll do a write up for the Wiki. :)


Actually, i just hand wrote a makefile and imported my "scalingtest1" directory as a project using File -> Import Project.

This is my makefile right now:

Code:
all: main

main: main.o
	gcc -lSDL -lSDL_image -lSDL_gfx -lstdc++ main.o -o main
	
main.o.: main.cc
	gcc -c `sdl-config --cflags` main.cc
 
Last edited by a moderator:
Just a break, I did some similar evaluation in other platform, quite close to GPH, with the following findings:

1. QVGA resolution is definitely not enough for graphics / scanned eBook
2. Assume that your eBook is JPEG encoded, you would need to handle jpeglib in certain extend for zooming partial image, due to limited memory and limited processing power
 
Back
Top