New Sprite editor

sigflup · Post by **sigflup** » Mon Sep 06, 2010 12:08 pm

I want you fellas to try out my sprite editor. It's for the sega-genesis, the project url is
http://uberleethackerforce.deepgeek.us and is under the prods section.
The direct url is http://hobones.dogsoft.net/mega/mega_distrib.tgz

this is for unix and should compile just find under linux. It's
perfectly usable and is my favorite editor out of others that i've
used. It stores/loads/edits vram cram and vsram dumps and auto-fills
the pattern table when editing new things. Doesn't support the window
as of yet and sprites (as is not the scroll planes) is a little tricky
but possible. There's a bunch of examples in the examples directory including a sonic 2 dump.

Let me know if you have any problems and what you think.

tails92 · Post by **tails92** » Mon Sep 06, 2010 2:29 pm

I have compiled it on NetBSD/amd64 but it gives me a segfault. I haven't investigated that much, however.

Anyway, in the Makefile instead of calling bin2head directly you could make perl execute bin2head:
perl ./bin2head <etc. etc.>

On other operating systems, very often perl isn't at /usr/bin/perl.
Also the CFLAGS seem to be a bit inconsistent between the main Makefile and the Makefile for the gui (like -m32 for the gui, -ggdb only for the main part, etc.)

I think -m32 should be removed completely.

Let me add that it is nice that tools like this are open-source and written for *nix-like operating systems, as there is a serious shortage of console game modding/hacking tools on these platforms.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Mon Sep 06, 2010 2:32 pm

Things like that make me wish I'd move my rear end faster regarding installing some flavor of Linux on some of my HDDs...

sigflup · Post by **sigflup** » Tue Sep 07, 2010 4:46 pm

@tails92

Ok- I've made it a bit more consistent. I am going to keep -m32 however because it doesn't run natively on a 64bit system and I don't have a 64bit system to test it on. It's gonna have to be 32bit for the moment. I've never run in on netbsd so awesome! Do you mind downloading it and running it again and this time if it segs could you give me the output of

$ gdb mega mega.core
backtrace

and let me know where it crashed so i can try and fix it?

Chilly Willy · Post by **Chilly Willy** » Wed Sep 08, 2010 4:58 am

sigflup wrote: I am going to keep -m32 however because it doesn't run natively on a 64bit system and I don't have a 64bit system to test it on. It's gonna have to be 32bit for the moment.

Get rid of the -m32. It takes much more than that to make a program compile as 32 bit on a 64 bit system. Just adding -m32 and thinking it will now compile as 32 bit is fooling yourself.

The only real way to compile a 32 bit program on a 64 bit system is to chroot into a 32 bit system with a 32 bit compiler.

sigflup · Post by **sigflup** » Wed Sep 08, 2010 2:25 pm

Chilly Willy wrote: Get rid of the -m32. It takes much more than that to make a program compile as 32 bit on a 64 bit system. Just adding -m32 and thinking it will now compile as 32 bit is fooling yourself.

The only real way to compile a 32 bit program on a 64 bit system is to chroot into a 32 bit system with a 32 bit compiler.

I think i'll keep it. I've had success compiling and running on a 64bit linux machine with that argument, it's never produced a wrong elf32 for me. Besides, compiling with a different compiler for the job doesn't strike me as the correct solution and so therefor i rather not.

*braces self for a flame war*

Chilly Willy · Post by **Chilly Willy** » Wed Sep 08, 2010 5:06 pm

No flames.

-m32 only makes that one item being compiled output 32 bit object code. As long as the rest of the makefile links together those 32 bit object files with 32 bit libraries, it shouldn't be an issue. The main problem is that most people just use lib specs like -lc or -lm, which on 64 bit machines are 64 bit libraries. -m32 does nothing for making sure that the libs will be 32 bit.

sigflup · Post by **sigflup** » Wed Sep 08, 2010 6:59 pm

Chilly Willy wrote:No flames.

-m32 only makes that one item being compiled output 32 bit object code. As long as the rest of the makefile links together those 32 bit object files with 32 bit libraries, it shouldn't be an issue. The main problem is that most people just use lib specs like -lc or -lm, which on 64 bit machines are 64 bit libraries. -m32 does nothing for making sure that the libs will be 32 bit.

ah, I see what your saying. Once I get a 64bit machine I'll have to debug all the issues out of it and have it run natively. Until then though I still think forwarding x11 over the net (my current access to a 64bit machine) is teh sux

Chilly Willy · Post by **Chilly Willy** » Wed Sep 08, 2010 8:20 pm

Yeah, that's a better idea. Just leave it until you can make it 64 bit clean (or until someone else does).

notaz · Post by **notaz** » Thu Sep 09, 2010 9:29 am

Chilly Willy wrote:-m32 only makes that one item being compiled output 32 bit object code. As long as the rest of the makefile links together those 32 bit object files with 32 bit libraries, it shouldn't be an issue. The main problem is that most people just use lib specs like -lc or -lm, which on 64 bit machines are 64 bit libraries. -m32 does nothing for making sure that the libs will be 32 bit.

Well if the compiler is correctly configured this shouldn't be really a problem, it can select lib32/lib64 as needed. It works on my Ubuntu system at least, with default gcc and lib32 dev packages.

8bitwizard · Post by **8bitwizard** » Sun Sep 12, 2010 12:03 pm

Chilly Willy wrote:No flames.

-m32 only makes that one item being compiled output 32 bit object code. As long as the rest of the makefile links together those 32 bit object files with 32 bit libraries, it shouldn't be an issue. The main problem is that most people just use lib specs like -lc or -lm, which on 64 bit machines are 64 bit libraries. -m32 does nothing for making sure that the libs will be 32 bit.

I think gcc does the right thing if you link using a gcc command with the appropriate -m option, for the command that generates the binary from the .o files.

I remember going nuts trying to figure out how to get the ld command to use the right CPU version of libraries until I realized gcc already knew how to run it properly.

Chilly Willy · Post by **Chilly Willy** » Sun Sep 12, 2010 4:55 pm

8bitwizard wrote:
Chilly Willy wrote:No flames.

-m32 only makes that one item being compiled output 32 bit object code. As long as the rest of the makefile links together those 32 bit object files with 32 bit libraries, it shouldn't be an issue. The main problem is that most people just use lib specs like -lc or -lm, which on 64 bit machines are 64 bit libraries. -m32 does nothing for making sure that the libs will be 32 bit.
I think gcc does the right thing if you link using a gcc command with the appropriate -m option, for the command that generates the binary from the .o files.

I remember going nuts trying to figure out how to get the ld command to use the right CPU version of libraries until I realized gcc already knew how to run it properly.

That may be it. I tend to use ld for all the linking and whatnot.

HardWareMan · Post by **HardWareMan** » Mon Sep 13, 2010 3:06 am

Make happy Windows users. :3