SegaXtreme

Home	Forums	What's new	Resources

PNG Support On Saturn

slinga - Mar 7, 2004

		slinga	Mar 7, 2004
		Hey guys, I was wondering if it was feasible to write a library to display png files on the saturn. Libpng is open source, and in C, but looks fairly complicated. Would the Saturn's CPU be able to handle this? My goal is not to make a pic viewer, but to be able to write a library that allows me to display PNG pics for animations, sprites, etc.

		antime	Mar 7, 2004
		Sure the Saturn can handle PNGs, but I don't know how good the format would be for realtime decompression. The best way to see if it suits your needs is to try it.

		it290	Mar 8, 2004
		Yeah, you'd probably have to load and decrunch everything beforehand. I'm not sure if PNGs can be uncompressed (the file, that is) or not, but if they can't, you'd probably be better off using an uncompressed format.

		vreuzon	Mar 8, 2004
		I don't see the point in doing the PNG to bitmap (or bitmap/pal) conversion at runtime. It would increase both program size (pnglib uses zlib) and startup time. Moreover, I believe that transparency, layers, etc. (handled by PNG) are not usefull in our situation. If you want people (including you) to be able to modify sprites, backgrounds, etc in your software without recompiling it (or if you are tired of big C arrays and conversions...), I believe it would be a better idea to use a more simple (uncompressed ?) format, too.

		slinga	Mar 8, 2004
		All I'm looking for is a simple way to display sprites, and seeing how all my balloon fight sprites are already in PNG format I figured I'd give PNG a shot After spending time with the library it doesn't seem too hairy. It already compiles, the only tricky things will be 1) use GFS_Open instead fopen() and 2) how to actually display the arrays of pixel data pointers (?). Other then that it, it's straightforward.

slinga

Mar 8, 2004

I got some weird errors. I'm including the png.h like the docs tell me to, and all of the structures work, but it can't find the functions for some reason. The first function I use after I copy the png file to memory is png_sig_cmp. If I call the function, the compiler complains that it can't dreference the function:

main.o(.text+0x254):main.c: undefined reference to `png_sig_cmp'

Now if I copy and paste the function from png.c to main.c, everything works fine, and the code compiles. It even works, correctly telling me if the file in memory is a png or not.

Unfortunately I can't figure out how to fudge the next functions to work. Do you guys have any idea why my main file can't access the functions, but can access the png structures? Do I have to make modifications to my makefile or objects file? Thanks in advance.

		vreuzon	Mar 9, 2004
		Are you sure you did add the pnglib binary objects generation to the makefile for it to be compiled ? Is the prototype of png_sig_cmp function in png.h ?

		antime	Mar 9, 2004
		That's a linker error message, and probably means you forgot to link against the libpng library.

slinga

Mar 9, 2004

Forgive me but I'm a complete idiot when it comes to makefiles and object files (spoiled by visual studio :devil ).

Objects

Code:

    # source_program SRCS = main.c SYSOBJS = $(CMNDIR)/cinit.o $(SGLLDR)/sglarea.o OBJS = $(SRCS:.c=.o) LIBS = -lcd -lsgl

Makefile

Code:

    CMNDIR = ../common include ../common/Makefile.template

Makefile.template

Code:

    # # SEGA SATURN Graphic library make file for GNU # Modified May 4 2003 by Ex-Cyber # Uncomment the GNUTARGET definition that matches your toolchain. # sh-coff: For e.g. KPIT's GNUSH COFF toolchain. # sh-elf: For e.g. a preexisting Dreamcast toolchain. GNUTARGET = sh-coff- #GNUTARGET = sh-elf- # macro CC = sh-coff-gcc LD = sh-coff-ld CONV = sh-coff-objcopy # The command to use for deleting files/directories. RM = rm #RM = deltree #RM = del /s # The SGL base directory. This needs to be an absolute path. #SGLDIR = /home/username/saturn/sgl SGLDIR = d:/satprog/sgl SGLIDR = $(SGLDIR)/inc SGLLDR = $(SGLDIR)/lib OBJECTS = ./objects # option CCFLAGS = -O2 -m2 -g -c -I$(SGLIDR) # -m2 must be specified in LDFLAGS so the linker will search the SH2 lib dirs # Specify path of libsgl.a by using "-L" option # Sega's ld might not understand the --format command used here... LDFLAGS = -m2 -L$(SGLLDR) -Xlinker --strip-debug -Xlinker --format=coff-sh -Xlinker -T$(LDFILE) -Xlinker -Map \ -Xlinker $(MPFILE) -Xlinker -e -Xlinker ___Start -nostartfiles DFLAGS = # source_program include $(OBJECTS) TARGET = sl.coff TARGET1 = sl.bin LDFILE = $(CMNDIR)/$(TARGET:.coff=.lnk) MPFILE = $(TARGET:.coff=.map) MAKEFILE = Makefile all: $(TARGET) $(TARGET1) # Use gcc to link so it will automagically find correct libs directory $(TARGET) : $(SYSOBJS) $(OBJS) $(MAKEFILE) $(OBJECTS) $(LDFILE) $(CC) $(LDFLAGS) $(SYSOBJS) $(OBJS) $(LIBS) -o $@ $(TARGET1) : $(SYSOBJS) $(OBJS) $(MAKEFILE) $(LDFILE) $(CONV) -O binary $(TARGET) $(TARGET1) # Redundant linker script was here # suffix .SUFFIXES: .asm .c.o: ifndef GNUTARGET @echo "You need to define GNUTARGET in Makefile.template." @false endif ifndef SGLDIR @echo "You need to define SGLDIR in Makefile.template." @false endif $(CC) $< $(DFLAGS) $(CCFLAGS) -o $@ clean: $(RM) $(OBJS) $(TARGET:.coff=.*)

Edit I used vreuzon's slime volleyball objects file as a source, and it seems as the only modification he did was to list the additional .c files in the SRCS line. I tried that but then it gives me an error saying it has no rule to make png.o needed by sl.coff.

Isn't this the rule: OBJS = $(SRCS:.c=.o)?

slinga

Mar 11, 2004

What if I compiled the png files into png.a or something like that? Then I could just link to it like the rest of the libraries...Now how do that? I'm guessing I'd have to do the same for Zlib as well.

Edit: Ok I figured out how to make them libraries. Only thing is I still get undefined reference errors, different ones though this time.

Edit 2: @#$@#$#@$@#$#@$#@$@#$@#$#@!@%@#$!@$@!#$@!#%!@@#$@#

Solved my problem.

# source_program

SRCS = main.c

SYSOBJS = $(CMNDIR)/cinit.o $(SGLLDR)/sglarea.o

OBJS = $(SRCS:.c=.o)

LIBS = -lpng -lz -lcd -lsgl

is not the same as

# source_program

SRCS = main.c

SYSOBJS = $(CMNDIR)/cinit.o $(SGLLDR)/sglarea.o

OBJS = $(SRCS:.c=.o)

LIBS = -lcd -lsgl -lpng -lz

This is stupid crap. Top one works, bottom doesn't. I HATE MAKEFILES

mrkotfw

Mar 13, 2004

I've been doing gbadev since December, starting with ARM assembly then programming in C. One of the most useful things from assembly is '.INCBIN'. .INCBIN let's you include a binary then export it as an array, it's VERY small and gcc-3.3.3 supports it... just a suggestion. So there's no need for large C arrays anymore!

Code:

    .ARM .TEXT .GLOBL bg0 bg0: .INCBIN "bg0.raw"

Code:

    extern unsigned long bg0[];

I don't know about SH assembly but you can at least give it a try. as for PNG support I don't think it's a good idea... you'd just be wasting your time imho!

oh, and i LOVE the Segaxtreme shirts!

Anyone wanna buy me one? :cheers

		slinga	Mar 19, 2004
		Stuck on some function call crashing the program (png create struct)...project's not dead but I'm going to Spain for 2 weeks, then London...

vbt

Apr 6, 2004

Originally posted by slinga@Mar 20, 2004 @ 02:47 AM

Stuck on some function call crashing the program (png create struct)...project's not dead but I'm going to Spain for 2 weeks, then London...

Dd you make some progress

and have good holidays ?

		slinga	Apr 10, 2004
		I'm in London for one more day

		slinga	Aug 9, 2004
		Still crashing *@$#@$@#$@#