kusfo wrote

Our WIP Lashiec tool!

kusfo wrote

For now it's only for sega megadrive, but probably it could be adapted to master system without much effort.

We'll make it public when it's less buggy...but if you want to try it, I can give you access to it...

haroldoop wrote

Technical explanation on how the rotating tower on Mickey Mania was done:



Pretty simple, once explained. Sounds like something that could be done on the SMS, too. ;)

djbass wrote

haroldoop wrote

Technical explanation on how the rotating tower on Mickey Mania was done:



Pretty simple, once explained. Sounds like something that could be done on the SMS, too. ;)

I've been considering whether many of his hacks would work on SMS but to my inexperienced mind it seems the SMS VDP is too limited to use the same tricks (things like lower sprite limit and no direct pixel addressing).

eruiz00 wrote

Ummm.... Last post make me remember tululoo gamemaker, the awesome tool with i began to learn JavaScript. As It has the src Code released' could be interesting a change in its backend to do an sms maker. Could need an genéric engine too, but the one It has It was flexible (a Sort of flixel, but simpler) i made three or four games on It and It was a pleasure!

sverx wrote

What about importing music and SFXs in VGM format and convert them?

haroldoop wrote

eruiz00 wrote

Ummm.... Last post make me remember tululoo gamemaker, the awesome tool with i began to learn JavaScript. As It has the src Code released' could be interesting a change in its backend to do an sms maker. Could need an genéric engine too, but the one It has It was flexible (a Sort of flixel, but simpler) i made three or four games on It and It was a pleasure!

I see what you mean:
https://github.com/naiduv/Tululoo
http://tululoo.com/

Well, yes, technically, unless its code does something really crazy (I haven't dived too deeply into its source) it should be possible to adapt it for making games for SMS; the sprite editor would have to be adapted to work with palettes (a lazier option would be to leave the editor as true color, but generate palettes on compilation, but that could lead to suboptimal results) and SMS's VDP hardware restrictions would have to be validated somehow to prevent the game from crashing.

So, basically, there's two ways this could be implemented:
1. Lazy option: Leave the editors as they are; on compilation, the palettes would be generated, the graphic assets would be resized and converted accordingly, the sound effects ignored (or use PSGTalk to make a rough conversion); it would also be the user's responsability to create the scripts according to SDCC syntax.
2. Better option: Create palette editors, make the graphic editors use the palettes, create SMS-compatible SFX/Music editors and make the script editors use SDCC syntax.

• The project is saved in a very straightforward and easy to understand XML file;
  
• The images are saved as PNGs;
  
• There's no true differentiation between background elements and sprites; some heuristics would have to be applied in order to determine what would be turned into a background;
  
• Uses JS as its scripting language; it would be necessary to use a parser to read its structure and then convert it to the C equivalent; of course, only a subset of JS would be supported by such a transpiler;
  
• Of course, there's the problem with the images, namely both their size and the palette.
  

• The project is saved as a bunch of easy to understand JSON files;
  
• The images are saved as PNGs;
  
• The maps are saved as CSVs representing the layers, plus a pair of JSON files for events and metadata;
  
• The scripts for the events are saved inside a JSON file, structured as a kind of AST; it looks like it would be relatively simple to generate C code from that;
  
• Of course, there's the problem with the images, namely both their size and the palette.
  

Maxim wrote

On the Master System, we don't have the luxury (or laziness, depending on how you look at it) of having the video memory exposed to the outside world, making this kind of thing much harder, although tmee's SMSDMA cart gets some of the way there through the keyhole interface we have to video RAM.

Quote

CROSS CHASE


This is a personal project whose goal is the creation of:

the universal 8-bit abstraction layer "Cross Lib" for coding universal 8-bit games
the "universal" 8-bit game "Cross Chase" that has to be a fun and that should run on (nearly) ALL 8 bit computers, consoles, handhelds and scientific calculators using the Motorola 6809, the MOS 6502, the Zilog Z80 and derivatives CPUs. The game will be the proof of concept of how flexible the library is.

How is it this done? This is achieved by having "Cross Lib" provide APIs for the game code. The game and library code are separated:

the game code only depends on the APIs interface and
the APIs do not depend on the game code. Therefore it must be possible to re-use the same library for other games/programs.
The program is written in ANSI C and currently compiled with

CC65 for all 6502 targets (http://www.cc65.org/),
SCCZ80 (from Z88DK) for most Z80 targets (https://www.z88dk.org/),
ZSDCC (from Z88DK) for some Z80 targets (https://www.z88dk.org/),
CMOC for most 6809 targets (https://perso.b2b2c.ca/~sarrazip/dev/cmoc.html),
WinCMOC for some 6809 targets (https://sourceforge.net/projects/cmoc-win32/).
For other targets, GCC6809 for other 6809 targets, sdcc (proper or its CPCTelera version), as well as "GCC for TI" for the Texas TI99/4a are being taken into consideration.