| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
Converting to sprites
Ok, so i have run into a problem.. hehe
I have 52 bmp pics, which are each the size of 2x2 C64 sprites.
So there's room for them all in 1 VIC bank..
Now problem is to convert them..
I tried Gang-Ed, but it only imports bmp as hires/mcol bitmap/char, and blows up the small image to fullscreen!
So i saved all the frames as a koala pr pic.. hahaha
Now i am stuck with 52 koala pics, that need to be transformed into 4 sprites each, bwahaha..
This is really silly..
What i really need is:
1) convert the 48x48 pixel bmp to 4 colors
2) convert this to 4 sprites
Is there an editor, where i can load bmp/gif into a sprite editor ? they have correct size, just need to be fixed to 4 cols.. which i can do with a batchconvert in thumbs plus (reduce nr of colors)
??
Thanks for any help! |
|
... 56 posts hidden. Click here to view all posts....
|
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Quoting BurglarI was thinking about writing a Makefile howto for codebase... Seems its needed for some people ;)
@Burglar: Please do! I certainly agree that some people would benefit from getting over that threshold, which is really quite low, considering that makefiles don't have to be complicated at all to be useful.
I've used makefiles for my C64 coding for quite a number of years now and using .bat/shell-scripts would of course be unthinkable. :)
Here is a quite generic little makefile that I found lying around on my harddrive. Maybe it can serve as inspiration or something... Of course it could be put in a simpler and more pedagogical way for someone who never used makefiles before, and it is not the optimal way of doing stuff in all cases there.. may even be some obsolete/erroneous lines in there.. but still.. just throwing it out here.. Maybe it helps someone.
"make" will result in the creation of a .d64 file with the assembled and crunched prg on it.
"make vice" will do the same thing, but also load the d64 with vice.
# Generic 6510 assembler makefile -- FTC/HT
#
# Assumes that all files named .a, .s, i., .inc., .asm are to be considered source files
#Project specific settings
NAME = template
STARTADRESS = 0800
STARTFILE = start.inc
POSTFIX = #.exe
# Names of main files and directories
TARGETDIR = bin
SRCNAME = code.a
PRGNAME = $(NAME).prg
D64NAME = $(NAME).d64
LABFILE = _vicelabels.txt
VICEOUT = _viceoutput.txt
# Generate a comprehensive source file list
SOURCEFILES =
SOURCEFILES += $(wildcard *.a)
SOURCEFILES += $(wildcard *.asm)
SOURCEFILES += $(wildcard *.i)
SOURCEFILES += $(wildcard *.inc)
SOURCEFILES += $(wildcard *.s)
SOURCEFILES += $(wildcard *.src)
# Tool locations
TOOLDIR = ~/sys/c64/devtools_mac
#TOOLDIR = ../_win32tools
#TOOLDIR = ../amigatools
# Specific tool locations
ACME = $(TOOLDIR)/acme/acme$(POSTFIX)
PUCRUNCH = $(TOOLDIR)/pucrunch/pucrunch$(POSTFIX)
EXOMIZER = $(TOOLDIR)/exomizer/exomizer$(POSTFIX)
C1541 = $(TOOLDIR)/vice/tools/c1541$(POSTFIX)
VICE = $(TOOLDIR)/vice/tools/x64$(POSTFIX)
#---------------------------------------------------------
# Create a .d64 with the prg on it
$(TARGETDIR)/$(D64NAME) : $(TARGETDIR) $(TARGETDIR)/$(PRGNAME)
@echo "*************************"
@echo "* Creating .d64... *"
@echo " "
@$(C1541) -format $(NAME),ht d64 $(TARGETDIR)/$(D64NAME) -attach $(TARGETDIR)/$(D64NAME) -write $(TARGETDIR)/$(PRGNAME) $(NAME)
@echo " "
#---------------------------------------------------------
# Assemble and crunch .prg file
$(TARGETDIR)/$(PRGNAME) : $(TARGETDIR) $(SRCNAME) $(SOURCEFILES) Makefile
@echo " "
@echo "*************************"
@echo "* Assembling program... *"
@echo " "
@echo " * = $$""$(STARTADRESS)" > $(STARTFILE) #Generate start adress file, included first in the sourcefiles
@echo " "
@$(ACME) -v2 --cpu 6510 -f CBM --vicelabeldump $(LABFILE) -o $(TARGETDIR)/$(PRGNAME) $(SRCNAME)
@echo " "
@echo "*************************"
@echo "* Crunching program... *"
@echo " "
@$(EXOMIZER) sfx 0x$(STARTADRESS) -m500 -p1 -x1 -p1 -t64 -o $(TARGETDIR)/$(PRGNAME) $(TARGETDIR)/$(PRGNAME) # > /dev/null
# @$(PUCRUNCH) -c64 -x0x$(STARTADRESS) -i0 -g0x35 -ffast $(TARGETDIR)/$(PRGNAME) $(TARGETDIR)/$(PRGNAME) > /dev/null
@echo " "
#---------------------------------------------------------
# Create TARGETDIR directory if it doesn't exist
$(TARGETDIR) :
@test -d "$(TARGETDIR)" || mkdir -p "$(TARGETDIR)"
#---------------------------------------------------------
# Open .prg file in VICE
vice : $(TARGETDIR)/$(D64NAME)
@echo "*************************"
@echo "* Open .d64 in vice... *"
@echo " "
@$(VICE) -truedrive +cart -autostart-handle-tde -moncommands $(LABFILE) $(TARGETDIR)/$(D64NAME) >>$(VICEOUT) 2>&1 &&
@echo " "
#---------------------------------------------------------
clean :
@echo "*************************"
@echo "* Cleaning... *"
@echo " "
$(RM) -f $(STARTFILE)
$(RM) -f $(TARGETDIR)/$(PRGNAME)
$(RM) -f $(TARGETDIR)/$(D64NAME)
$(RM) -f _*.txt
rmdir $(TARGETDIR)
@echo " "
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
@Frantic: So that was supposed to be "not complicated at all"!?!? Any makefile larger than 10 lines is complicated :P. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: @Frantic: So that was supposed to be "not complicated at all"!?!? Any makefile larger than 10 lines is complicated :P.
+1
Make is scary. I have only used it once so far: While it adds flexiblity and saves compile time on the other hand it adds an extra level of frustration. Fighting with it is not fun, so it will do what you want. If you're not familiar with it, and you only started to use it for your c64 project you will have trouble. |
| |
enthusi
Registered: May 2004
Posts: 677 |
Nah. You can make super plain Makefiles that look and act like a mere bash script.
THEN you can add ONE layer of complexity by adding dependencies, etc.
super-easy to learn, hard to master though. But for big gain in c64 projects you'd hardly have to master it.
it breaks down to:
game.prg: game.asm leveldata.bin
xa game.asm -o game.prg
leveldata.bin: level.asm charset.bin
xa level.asm -o leveldata.bin
charset.bin: charset.koala
convert charset.koala charset,bin
this has 3 'layers' already. Yet leveldata.bin will only be reassembled when level.asm or charset changed. It will automatically recognize if charset.koala changed even though level.asm might still be the same etc.
You can hardly call this complex. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"Make is scary."
you know what is _really_ scary? - supposedly decent coders proposing .bat files. /o\
not using make because it is "scary" or "hard" is pretty much like using basic over assembly because asm is "scary" and "hard". it boils down to "i am to lazy to learn it so i will pretend i dont need it". |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Agree with Oswald. I'm using Ant and Maven enough at work to get my need for boring configuration crap covered. When coding c64 I just want it to be fun and about hacking the c64. Will probably try out make someday though. |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
heh, gimme a few days to write the tutorial guys, but here are the simple most important rules:
JAVA=java
KA=-jar src/lib/KickAss-3.25.jar
KAFLAGS=-showmem -aom -symbolfile -afo -time
EXO=exomizer
EXOFAST=-m 4096 -p 1
EXOFLAGS=level -c -q $(EXOFAST)
EXOSFXFLAGS=sfx 0x1000 -n -q -D i_line_number=2013 $(EXOFAST)
%.prg: %.s
$(JAVA) $(KA) $(KAFLAGS) $< -o $@
%.prg.exo: %.prg
$(EXO) $(EXOFLAGS) $< -o $@
%.sfx.exo: %.prg
$(EXO) $(EXOSFXFLAGS) $< -o $@
and now you can just put bla.s in the same dir and type
unpacked:
make bla.prg
levelpacked:
make bla.prg.exo
selfextracting packed:
make bla.sfx.exo
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: Agree with Oswald. I'm using Ant and Maven enough at work to get my need for boring configuration crap covered. When coding c64 I just want it to be fun and about hacking the c64. Will probably try out make someday though.
edit: wanted to quote this:
"not using make because it is "scary" or "hard" is pretty much like using basic over assembly because asm is "scary" and "hard". it boils down to "i am to lazy to learn it so i will pretend i dont need it"."
basically that's me :)
I've been still using profi assembler when friends already had tass, and been coding on c64 when emulators were already good enough, and been coding in emulators when I should have been cross asming :) Now I'm here crossing (but denying to use anything more advanced than 64tass:), and promise I'll use 'make' too when I'll need to link again, but I really hate jumping through the firey loops of all the syntax shit whenever it comes to a new language/scripting/make whatever. It always takes a lot of time swearing and frustration. I hate that shit. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:gimme a few days to write the tutorial guys, but here are the simple most important rules:
hihi. this kind of "example" is what scares people away from makefiles IMHO (it was like that for me, that much i know =)). ie, dont start with something that uses tons of features at once, you dont need variables or implicit rules to get it going =) once you understand the very basic principle
target: ingredience
commands
...you can go from that and write more complicated stuff (your example will already give people a headache in cases of "i want to compile this source with different KAFLAGS")
copypasting someone elses makefile "that contains the important rules" without understanding it completely is about as bad as copypasting a kickass macro for sprite conversion without knowing exactly what it does - imho :)
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"basically that's me :)"
you know what? EVERYONE knows that, since ninjas talk =D |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
