|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
15th Anniversary Coding Competition progress report/discussions
Posted: Wed Jan 18, 2012 1:02 pm
|
Feel free to post ideas, reports, screenshots anything related to your ongoing work for the 15th anniversary coding competition. Exciting times ahead :) | |
|
Posted: Wed Jan 18, 2012 1:10 pm |
I started my work on a run 'n'gun type game for the competition.
I've done quite some graphics and I am working on the code side aswell as tools to create and help with various things. Only thing I am not certain is that if I am able to finish off my music making tools in time so there might not be FM and PSG music going on. |
|
|
Posted: Wed Jan 18, 2012 1:45 pm |
To be honest I'm slightly depressed because we have a few new(ish) participants who seem to be very capable so I'm going to have to try really hard :( | |
|
Posted: Wed Jan 18, 2012 2:09 pm |
@TmEE: What do you mean with 50Hz optimized? Is it related to the replay speed of the music?
Wouldn't it be 60Hz optimized then? As you can slow down the re-player pretty easy in 60Hz. But speeding it up on 50Hz is much harder ;) |
|
|
Posted: Wed Jan 18, 2012 2:33 pm |
Working on a Sokoban..ish game with the temporary title "Tower of Sokoban".
I know what you'er thinking: "Sokoban.. again? Booooring!". But this one has awesome graphics made by Alexander Berggren (BG) and (maybe) cool music made by Thematrixeatsyou. And it features monsters! (If I can make it work) :D Right now I'm trying to get some collision detection going. Since the game is tile-based, I'm actually using the VDP status flag to give the illusion of non-tile collision. Not sure, whether it will work. I'm very new to SMS programming (and programming in general), so my code is a mess. But just the fact that it does the things I want it to do, is immensely satisfying :) |
|
|
Posted: Wed Jan 18, 2012 2:43 pm |
Here is a screen shot of my project.
I started with porting an MSX music re-player (MoonBlaster). Once I got that one working I decided to pull up an old idea for a game and try to implement it on the SMS. Most specific SMS stuff (which I was not familiar with) is implemented (VDP updates (PGT, PNT SAT,) Joypad, mapper routines, start-up etc). Only thing I still have to decide on is how to implement the sound effects. (Where are those SMS sfx editors? o_O^) Perhaps some nice info for people making a game entry is this article: Collision Detection routine article+ source It helped me a lot when I started coding enemies. |
|
|
Posted: Wed Jan 18, 2012 3:48 pm |
You can do a whole lot more in 50Hz than you can in 60Hz. I detect which you run on and adjust things accordingly. For best results you want 50Hz. |
|
|
Posted: Wed Jan 18, 2012 4:08 pm |
But everything on the screen is squeezed together in 50Hz. It looks so bad :( | |
|
Posted: Wed Jan 18, 2012 5:06 pm |
It looks perfect on a widescreen TV, which is what everyone uses these days wanyway :P
In any case I am not throwing away the massive extra VDP performance that 50Hz gives ^^ |
|
|
Posted: Wed Jan 18, 2012 6:45 pm |
I feel the same way. After not completing my project last year, and seeing all these great work-in-progress reports, it makes my idea for a project seem much less interesting... |
|
|
Posted: Wed Jan 18, 2012 10:15 pm |
Those screenshots make me drool! I really can't wait! :-D | |
|
Posted: Thu Jan 19, 2012 10:33 pm |
Nobody feel scared please! Getting anything done is quite an accomplishement anyone can be proud of. It is very exciting to see things shaping up well this year.
I don't know yet if I'll have an entry but I'd like to state that anyone who needs an improvement of the MEKA debugger/tools please don't hesitate to ask. |
|
|
Posted: Fri Jan 20, 2012 8:09 am |
Setting breakpoints using labels (from symbol file) would be very nice. |
|
|
Posted: Fri Jan 20, 2012 9:55 am |
You can already do that it is one of the earliest feature the debugger had. "b label". You can use TAB to automatically completion a symbol name. Use "sym" or "sym xxx" to find symbols. |
|
|
Posted: Fri Jan 20, 2012 10:47 am |
I finished my linker program so I could create filesd beyond 64KB without assembler whining and I added basic VRAM transfer queue to maximize VBL use without too much messing around.
Now I got to work out sprite handling to get big sprites that act as single for the program and add sprite locations lists to my GFX converter so I won't have to manually align things etc. |
|
|
Posted: Fri Jan 20, 2012 11:30 am |
What assembler and what whining? | |
|
Posted: Fri Jan 20, 2012 11:58 am |
AS80, it won't like when stuff extends outside 64KB address range.
I have tried several other assemblers and they had interesting ideas of something or did not like my code, requiring tons of modications to it. SjasmPlus looked cool but it is not doing anything better than AS80, except for binary includes, but those are handled by the linker anyway so I got nothing to complain about anymore ^^ |
|
|
Posted: Fri Jan 20, 2012 12:13 pm Last edited by Zipper on Fri Jan 20, 2012 12:34 pm; edited 2 times in total |
Hmm. I see now. It works! Seems there are problems with Sjasm MODULE's eg "MUSIC.play". But I hardly use those. Thanks. I could not find it in the help inside MEKA. |
|
|
Posted: Fri Jan 20, 2012 12:19 pm |
Try this one sjasm by xl2s. I did a quick scan and it seems compatible with AS80 and is much easier to get started with then for example WLA-DX. It features much easier support when using a mapper than AS80. I use it with much pleasure. ;) |
|
|
Posted: Fri Jan 20, 2012 12:57 pm |
Zipper: lets resume the conversion about the debugger here : http://smspower.org/forums/viewtopic.php?t=13549 | |
|
Posted: Fri Jan 20, 2012 7:42 pm |
The assembler that comes with sdcc (sdasz80) assembles to object code with the equivalent of sections specified in the assembly code like this .area _CODE
Then you can compile that into a hex file, passing the address for the bank where the code will appear as an sdcc option. ramcode.bin:
$(AS) -o diskio_asm.s $(CC) $(CFLAGS) --no-std-crt0 --no-peep --code-loc 0xC800 neo2.c diskio_ram.rel diskio_asm.rel $(HEX2BIN) neo2.ihx $(PADTRIM) neo2.bin ramcode.bin $(MAP2H) neo2.map neo2.h diskio.h $(MAP2H) neo2.map --output-asm neo2.h $(RM) neo2.bin neo2.ihx neo2.asm *.noi *.lnk *.rst In the above code, the .asm file is assembled to an object file (.rel), then it is linked by sdcc along with the output of sdcc for neo2.c and another c file that was compiled to .rel elsewhere. The whole thing is linked to run at 0xC800, which is in ram in this case as we needed this code to run from ram as it controls the Neo Myth hardware. It could have easily been a frame in the SMS, like --code-loc 0x8000 for frame two. In fact, the neo myth menu has that too for the filesystem code: pffromcode.bin:
$(CC) $(CFLAGS) --no-std-crt0 --oldralloc --code-loc 0x8000 pff.c $(SHARED) $(HEX2BIN) pff.ihx $(PADTRIM) pff.bin pffromcode.bin $(MAP2H) pff.map pff.h $(RM) pff.bin pff.ihx pff.asm *.noi *.lnk *.rst This next block compiles to 0x0000 and 0x4000, frame 0 and frame 1: bank0.bin:
$(CC) $(CFLAGS) -c sd_utils.c $(CC) $(CFLAGS) -Wl-b_GSINIT=0x3400 --no-std-crt0 --oldralloc main.c $(BANK0OBJS) sd_utils.rel $(SHARED) $(HEX2BIN) main.ihx $(PADTRIM) main.bin bank0.bin $(MAP2H) main.map vdp.h pad.h util.h $(RM) main.asm bank1.bin: $(CC) $(CFLAGS) --no-std-crt0 --no-peep --code-loc 0x4000 bank1.c $(SHARED) $(HEX2BIN) bank1.ihx $(PADTRIM) bank1.bin bank_1.bin $(MAP2H) bank1.map bank1.h $(RM) bank1.bin bank1.ihx bank1.asm *.noi *.lnk *.rst The hex files (.ihx) are converted to a plain binary that can be joined together to make the rom, then the header added: menu.sms:
cat bank0.bin bank_1.bin ramcode.bin bank0.bin bank0.bin pffromcode.bin vgmcode.bin bank0.bin > menu.sms $(SMSHDR) menu.sms PADTRIM just pads the binary to 16K to make a nice block for joining. MAP2H takes the h file for the code along with the linker map generated and creates another h file with absolute addresses for the functions in the block so that other code can call the block without knowing what the entry addresses are. The data section is set similarly with a command line option: --data-loc 0xC000
|
|
|
Posted: Sat Jan 21, 2012 8:32 am |
I just run my SMSLINK.EXE that looks into LINKFILE.TXT which contents right now are this :
BANKDATA.ASM
BANKDATA.BIN 4 TitleGFX OIF\TITLE2.OIF TmEElogoGFX OIF\TMEELOGO.OIF SMSpad OIF\SMSPAD.OIF MD3pad OIF\MDPAD.OIF BANKDATA.BIN is the file that you append to your 32KB code block that your assembler would spit out. 4 denotes that there is 4 files to process TitleGFX is the name of the EQU that gets used in BANKDATA.ASM and inside your program. The rest is location your file that you want in your program. Here's an output of the linker program : Tiido's kickass SMS/GG ROM linker v0.1
Processing : OIF\TITLE2.OIF Processing : OIF\TMEELOGO.OIF File is too big to fit into a bank, starting new bank Unused bank space : 2588 Bytes Processing : OIF\SMSPAD.OIF Processing : OIF\MDPAD.OIF The program will tell how much unused space there will be when a file does not fit into current bank so you could later on put a small file in there to fill the gap. There's several other messages that are quite self explanatory but you won't see them often. BANKDATA.ASM that linker generates which gets included in assembly process will contain this info : ; #### Data locations that linker put here ####
; These files are inside bank 2 TitleGFX EQU $8000 ; These files are inside bank 3 TmEElogoGFX EQU $8000 SMSpad EQU $8C6E MD3pad EQU $9B92 So my build process looks something like that : @echo off
SMSLINK.EXE AS80-DOS -i -x3 -n -z -lnul RAT.ASM CHECKSMS RAT.BIN DEL RAT.SMS COPY /B RAT.BIN + BANKDATA.BIN RAT.SMS DEL RAT.BIN SMSLINK.EXE is not ran in the BAT file as there's no need to rebuild data that does not mostly change around. I create a new bank file when I need it to happen. Will spare a second of time haha. CHECKSMS.EXE will add a valid checksum and a "Last assembled on date+time" string right before "TMR SEGA" I find this arrangement quite simple and elegant, and if anyone likes this aswell I can post the tool. Beware of MS-DOS though, but it worked perfectly on XP. Probably won't work on 64bit setups, but will inside DOSbox haha |
|
|
Posted: Sat Jan 21, 2012 10:08 am |
I'm not even on the radar when it comes to my ability to program the Master System, but it is quite exciting to see people taking on the challenge and running with it, if anything it pushes me to do even better which is a good thing. We need talanted creative people like this to fuel the scene onto bigger and better things. In support of Bock's comment every contribution is welcome, it's a tough system to develop for and even getting a basic sprite or single tone to work is a worthy technical merit of it's own. Not in the least your examples Maxim have inspired many of these people to take up the challenge in the first place and that is a greater contribution than any. |
|
|
Posted: Sun Jan 22, 2012 4:43 am |
Yeah, that looks pretty simple for folks just using the assembler. Some folks would rather have simple in any case. :) DOS is also an issue for linux folks... we have to use dosbox to run it instead of wine, but fortunately dosbox now makes it pretty simple to run simple DOS commands from the shell - it's almost like running a regular command. |
|
|
Posted: Sun Jan 22, 2012 11:26 am |
I got to see about running my stuff through FreeBASIC, most of it is more or less directly compilable, others (like my GFX converter) would need very extensive modifications..
The linker should be one of the directly compilable things. EDIT: I got some stage data decompression and showing to work :D Next step is scrolling ! EDIT2: I have scrolling now :D |
|
|
Posted: Tue Feb 21, 2012 9:20 am |
Looking great.
I'm still very busy coding but have reached the hardest part.... making the levels.I surely hope to be on time to make enough levels to make it a fun game. I totally skipped trying to compress any data so current size is 512Kbyte. P.S. Perhaps this site might give some people some inspiration/motivation to cook up something: MSXdev competition. It contains lots of great games (some even with source code). Some are big projects some are small. The competition shows that everyone can make a game with some help. |
|
|
Posted: Tue Mar 06, 2012 7:47 pm |
It is less and less likely I will get my game into any shape for the compo, I would be barely making in with music. Real life takes too much time... | |
|
Posted: Fri Mar 16, 2012 2:17 am |
Well, I think I'll try to rush something simple during the weekend. It probably won't be anything great, but it's still better than nothing at all. | |
|
Posted: Fri Mar 16, 2012 9:53 am |
It'll be better than what I'm doing then :) | |
|
Posted: Mon Mar 26, 2012 6:40 am |
Getting close to the deadline and only one coding entry in... I hope everyone else is planning something last-minute. | |
|
Posted: Mon Mar 26, 2012 6:50 am |
I'm franticly working to enter with an entry...... |
|
|
Posted: Mon Mar 26, 2012 9:02 am |
Life got in the way and stole a good good chunk of time I would have used for my entry...
I don't think there will be any music coming from my tracker, unless some improvisation would do that is not even using PSG, only simulating it... And my game is far too unfinished to be worthwhile (only a scroller and some pretty graphics here and there) |
|
|
Posted: Mon Mar 26, 2012 12:57 pm |
Unfinished submission is better than none :) | |
|
Posted: Mon Mar 26, 2012 2:30 pm |
Yes true, I'm trying to add gravity and some colission detection in it and perhaps some real jump through stage too... I certainly won't have the time for an animation setup though, or rather, drawing the animations... | |
|
Posted: Mon Mar 26, 2012 5:28 pm |
I just sent you our entry. Ichigobankai made the graphisms/animation and the level design, I wrote the code. I hope you've received it, if you didn't please contact Ichigobankai because I won't log in before at least wednesday ! | |
|
Posted: Mon Mar 26, 2012 6:06 pm |
If it's like any last-weekend-before-the-competition I've participated in, you will need the rest :) I've got it, looking forward to seeing some more entries...
Please remember you're welcome to submit bugfixes at any time, I'll try to stay on top of it. |
|
|
Posted: Mon Mar 26, 2012 9:12 pm |
I will send in my WiP game attempt and some realtime keyboard+fingers created sounds(mostly chords and some melodies) from my tracker tomorrow. | |
|
Posted: Wed Mar 28, 2012 9:28 am |
I was going through the coding entries ROMs to see maybe some hidden messages etc. and I kept on noticing a certain line before TMR SEGA in other people's ROMs... then I saw it in my ROM too and now I wonder if it is some new expanded header or something ?
I got my TMR SEGA at 8KB point rather than 16 or 32KB, and the line of text appeared in the 32KB point in my ROM. I guess it would have been added to the 8KB point but I got the preceding bytes occupied by "Last assembled on..." message. Is there any info about it ? I'm curious, I would have added it myself ^^ |
|
|
Posted: Wed Mar 28, 2012 10:51 am |
I guess the SDSC header was added by the SMSpower crew. More info: http://www.smspower.org/Development/SDSCROMTagSpecification |
|
|
Posted: Wed Mar 28, 2012 11:36 am |
Yes, I added SDSC headers to all entries, which I planned to post about before you noticed :)
If it causes any issues, please let me know. In future I intend to make it a competition entry requirement. It's for your benefit, as it makes sure you get credited. Also, having your header at $1ff0, and only checksumming 4KB, is a first :) |
|
|
Posted: Wed Mar 28, 2012 12:07 pm |
I thought it would save time on real hardware having a tiny part of the ROM checksummed, but it seems savings are quite minimal.
The header won't cause issues, that area is not touched in the game so it can happily live there. I would have used my real name instead of "TmEE", and the ROM name string could be the one in very beginning of the ROM. First in homebrew or first ever ? I would think there's several other titles etc. doing same thing... Which now makes me wonder if SDSC header could appear elsewhere too, i.e where I got normal header, to keep things consistent in the ROM ...? In any case I will make my future ROMs have that header in it. |
|
|
Posted: Wed Mar 28, 2012 12:51 pm |
Sorry for doing it at the last minute, I didn't have time to check. You're welcome to post an update, especially if you have anything else to add.
The SDSC tag doesn't have an optional location, it'd break current software to change that. In fact, a Sega header at $7ff0 could still have a 4KB checksum range and it'd save a few more cycles. The typical case of paging from $8000-$bfff means it's conveniently not in the middle of your code/data. No software, homebrew or commercial, has a header anywhere but $7ff0. But all (normal) BIOS revisions support the alternative locations. |
|
|
Posted: Wed Mar 28, 2012 1:19 pm |
The main reason I got the header at 1FF0 is becuase at first the ROM is tiny and I did not want to pad it to 32KB, it also saved flashing time when I tested the stuff, though it loses the effect once the ROM is past 32KB... so the headers just got "stuck" at that point, I can also add code and data without worrying about destroying the header later on.
I'm not seeing how allowing the header to be elsewhere could break existing stuff, but now knowing I am the one doing things "wrong" I might aswell adjust to it :P |
|
|
Posted: Wed Mar 28, 2012 2:10 pm |
No, I meant the SDSC header isn't moveable, the TMR SEGA can be in three locations - but any software that deals with the latter (I only know of one: the one that GoodSMS uses to determine regions) is likely not to work properly. It's only my reverse-engineering of BIOSes that had made it known that the other locations will work.
My overall point was that the SDSC header is good, the Sega one is good, you may as well put them together at the usual place. |
|