New Sprite editor
Moderator: BigEvilCorporation
New Sprite editor
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.
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.
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.
-
- Very interested
- Posts: 2443
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Things like that make me wish I'd move my rear end faster regarding installing some flavor of Linux on some of my HDDs...
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
@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?
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?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.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.
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.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.
*braces self for a flame war*
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 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.
-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 suxChilly 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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.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.
-
- Very interested
- Posts: 159
- Joined: Sat Feb 24, 2007 11:35 pm
- Location: San Antonio, TX
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.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 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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
That may be it. I tend to use ld for all the linking and whatnot.8bitwizard wrote: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.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 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.
-
- Very interested
- Posts: 746
- Joined: Sat Dec 15, 2007 7:49 am
- Location: Kazakhstan, Pavlodar