Sublime Text Build System for SNES

I made a video for a build system I made in Sublime Text for SNES check itttt:
https://www.youtube.com/watch?v=Syg1kzBPyXU

If you want the actual build system it is over here:

https://github.com/BenjaminSantiago/Sup ... ublimeText

That's dope. I use Sublime. Why not add a note to Readme.md that your build only works for single-object jobs. But this also serves as a good template for someone who might want a sublime build system for his multi-object project.

Also, cool ROM u made there.

Yeah, I'm hoping I can eventually also make it smart enough to assemble everything if I have sound code as well, haven't tested the limits of robustness of sublime text in that regard.

I haven't messed around with using multiple objects, what kind of stuff do you do with them? Honestly, I'm still trying to get a hold of programming things that are closer to full games before I start playing with stuff like Mode7/transparency or do more things with the assembler.

Also do you just use a command prompt/.bat or what? Just curious

The build system used in my Super NES project template uses ca65 and GNU Make.

The most extensive build system I've for SNES / SPC700 used GNU make. Wla DX has flag/option to output a Make recipe, which I would "batch compile" all source files recipes into a Makefile.. it's a pretty custom job I guess if we took a look at it u could get a feel for it.. But it's good for getting organized so you don't have to include a million files into one main file.. lemme take a look at my ol' project dir.. O_O omg this looks so Greek to me lol.. I can tell you they are good at preventing you from compiling an entire code-base over and over again. like when you .INCLUDE all your files into the main ASM file , that means you are recompiling the same code over and over and over again even if a lot of it doesn't change at all, like the INIT code for instance.. By seperating shit to compile seperate objects and using "something" like Make to manage the dependencies and build rules, you have a much more manageable system. But the complexity is much higher because now you have to understand how to do shit in Make.. like automatically creating the dependency information for instance.. But if you can figure it out, it's a big help :] It can automate alot and prevent the rebuilding like I was saying..

You'll come to a point at your journey in developing a game when you start having a lot of "Shit" everywhere, you'll want to organize it and maybe you'll get away with using Make eheheh IDK. It's one of those things thats a bitch IMO but useful

I dont consider this thing useful by any means, I can hardly understand it myself, but it's an example of a sophisticated build setup: https://github.com/bazzinotti/SNES-Trac ... leProtocol

it is by no means "Simple" haha at least in build environment -- but, um, this code base also demonstrates a Simple protocol between the SPC700 and the SNES.. Use it, thank me.

d4s' SNES work is the most impressive publicly shared I've seen. The object oriented runtime created for Super Road Blaster is quite a trip, as is the makefile.

Personally I'm taking a new stab at SNES coding at the moment. I decided not to use WLA this time around since it's not likely to be improved and I'm fed up with the limitations of it's macro preprocessor so I'm probably going with ca65.

As for build system/scripting, I've been experimenting with Rake and Tup. Really digging Tup, but it's dependency on FUSE for file system monitoring is kinda concerning..

Thanks guys. I come from an art/design background so my experience with programming hasn't included make yet (I started with HTML/CSS/Javascript and Actionscript in highschool and eventually learned Processing which is built on top of Java).



ahhhhh cool. I actual follow a follow a similar file structure except I usually move the output to a ROM folder and separate graphics produced in photoshop from what is used in the game/demo.




Cool, I can't really tell what is going on (yet) but glad you are still working on that tracker!




What is your beef with macros in wla? How do you work with spc/audio code then? Also, at some point I came across your 65816 syntax highlighting, cool stuff!

For SPC/audio code, I use a ca65 macro pack that Blargg wrote. It implements both the vaguely Intel-style "official" SPC700 syntax and the 65C02 syntax.

Hm Ca65 sounds really nice and there was a time when I learned it and started modeling projects after Mukunda's Skipp and Friends, but I never attached to it. I also understand that cc65 (and subsequently ca65?) is no longer being developed / supported: see http://www.cc65.org/

If this is true, .. I dunno, I'm not having any problems with WLA yet :B .. Although I do vaguely remember having problems adjusting to wla-spc700 syntax vs. TASM.. just FYI

cc65's maintenance moved over to github. It's quite active.

The thing that made me give up on WLA was the inability to use some assembler directives from within a macro (which doesn't make sense since it's a preprocessor) combined with it's rather messy codebase (ie. no joy to be found hacking on it).

For SPC code I'll probably stick with WLA for the time being, but I'll take a look at the aforementioned macro kit for ca65 as well!.