A small Java tool to convert short animation loops to be played on MSX computers. This is the code that was used to generate the flag animation in the game XRacing ( https://github.com/santiontanon/xracing ).
The input is a GIF file, and the output is a collection of .asm file with the data necessary to play the animation. The data is divded into 2 parts:
Tiles/attributes: to be copied to each of the three banks of the VDP (the converted assumes MSX1 with Screen 2).
Name tables: the name tables of each of the animation frames, to be copied to the VDP at each frame.
Additionally, just to see the animation in an MSX. The tool prepares a small .asm file to show how to play the animation, and compiles it into a ROM that can directly be open on an MSX emulator.
The way the program works is by figuring out all the different tiles needed in each of the 3 banks to play the animation. Since only 256 tiles can be loaded at once, it assumes that only the name table can change from frame to frame, and it uses an automated clustering algorithm (k-medoids) to reduce the number of tiles to 256 (or to a smaller number if specified), in order to get an approximation of the animation.
GB studio is a visual tool for making games for the Gameboy:
Quote
Make GB games in minutes. Play in an emulator or your browser.
A free and easy to use retro adventure game creator for your favourite handheld video game system.
Create Real ROM files: Run your games on any compatible emulator, if you've got a flash cart you can play them on a real console!
Simple Setup: No complicated dependencies to install, just a single application with everything you need to get started.
No knowledge required: Simple visual scripting means you don't need to have made a game already. GB Studio also hides much of the complexity in building GB games so you can concentrate on telling a great story.
Build for the web: GB Studio comes with a web based emulator that even works great on mobile. You can quickly export your games to play in a browser or even upload to Itch.io.
- Visual game builder with no programming knowledge required.
- Design your graphics in any editor that can output PNG files e.g. Photoshop, Tiled, Aseprite.
- Example project included to get started right away.
- Make top down 2D JRPG style adventure games.
- Build real GB Rom files which can be played in an emulator or on device using USB Carts.
- Build a HTML5 playable game that also works on mobile and can deployed to any webserver or uploaded to Itch.io.
- Built for macOS, Windows and Linux.
- Supports both macOS light and dark mode.
- Includes the full tools that were used to build Untitled GB Game, free to play on Itch.io.
An experimental tool to automatically convert pop music to chiptunes:
Quote
In this paper, we propose an audio mosaicing method that converts Pop songs into a specific music style called “chiptune,” or “8-bit music.” The goal is to reproduce Pop songs by using the sound of the chips on the old game consoles in 1980s/1990s. The proposed method goes through a procedure that first analyzes the pitches of an incoming Pop song in the frequency domain, and then synthesizes the song with template waveforms in the time domain to make it sound like 8-bit music. Because a Pop song is usually composed of the vocal melody and the instrumental accompaniment, in the analysis stage we use a singing voice separation algorithm to separate the vocals from the instruments, and then apply different pitch detection algorithms to transcribe the two separated sources. We validate through a subjective listening test that the proposed method creates much better 8-bit music than existing nonnegative matrix factorization based methods can do.
Moreover, we find that synthesis in the time domain is important for this task.
Spleeter uses machine learning to separate audio input into vocals, drums, bass and others; I imagine a similar concept could be used for better wav-to-psg conversions?
apuultra is an alternative apLib packer; on average, it compresses 5 to 7% better than apack while still mantaining compatibility, that is, the packed data can still be unpacked using the same old apLib routines.
Quote
apultra is a command-line tool and a library that compresses bitstreams in the apLib format.
The tool produces files that are 5 to 7% smaller on average than appack, the apLib compressor. Unlike the similar cap compressor, apultra can compress files larger than 64K (for files smaller than 64K, cap compresses 0.2% better on average).
apultra is written in portable C. It is fully open-source under a liberal license. You can continue to use the regular apLib decompression libraries for your target environment. You can do whatever you like with it.
Bitsy Game Maker is a pretty simple game making tool; its games use 8x8 1bpp tiles arranged into a 16x16 grid.
Its script format looks pretty easy to parse; I'm thinking whether I shouldn't implement a converter...
Quote
Hi!
Bitsy is a little editor for little games or worlds. The goal is to make it easy to make games where you can walk around and talk to people and be somewhere. I hope you enjoy using it!
Bitsy converter allows one to convert Bitsy scripts into various output formats; for now, it has full JSON support, and partial Arduboy support; more formats will come later.
All you have to do is paste the script on the left panel, and the converted result will be displayed on the right panel. On the top of the right panel, there are also tabs for choosing the desired output format.
It works by forcing the phase generator to hold on a specified phase using test register bit 2. This allows it to index into the sine table and produce accurate near 8-bit sample playback with a simple inverse lookup table.
It reminds me what I was trying to do for this year competition, still buggy as hell, but....
That's a pretty good start! Using different colors for y-aligned walls versus x-aligned walls should improve the visibility without too much additional effort; also, if you don't intend to use textures, it would be possible to use dithering to make distant walls look darker.
"“Turbo Rascal Syntax error, “;” expected but “BEGIN” (Turbo Rascal SE, TRSE) is a complete suite (IDE, compiler, programming language, image sprite level resource editor) intended for developing games/demos for the 8 / 16-bit line of computers, with a focus on the MOS 6502, the Motorola 68000 (Amiga 500, Atari ST), the GBZ80 (gameboy), the Z80 and the X86, supporting the C64, C128, VIC-20, PLUS4, NES, Gameboy, PET, ZX Spectrum, TIKI 100, Atari 2600, 8086 (CGA). With the benefits of a modern IDE (error messages, code completion, syntax highlighting etc) and a bunch of fast built-in tools, it has never been easier to program for your favorite obsolete system!TRSE runs on Windows 64-bit, Linux 64-bit and OS X. Development began on Feb 24th 2018. The TRSE framework contains a number of project examples for multiple platforms, including almost 40 runable tutorials.TRSE also contains a real-time ray tracer that can export data (screens, charsets) to the C64/Amiga etc.
Please note that not all systems are implemented with 100% support yet:
It reminds me what I was trying to do for this year competition, still buggy as hell, but....
That's a pretty good start! Using different colors for y-aligned walls versus x-aligned walls should improve the visibility without too much additional effort; also, if you don't intend to use textures, it would be possible to use dithering to make distant walls look darker.
Thanks for the advice Haroldoop! I'm thinking on having different tiles depending on the alignment of walls and the distance, but first I've to solve some of the errors present in the current demo :-D
Really impressive! I don't know if it relies on one of the bitmapped formats, but otherwise should be doable on the SMS...
If this is using only ⅓ of the height of the screen, so 8 tiles, it needs 256 tiles to have a proper bitmap. Also this means you have to push 8 KB to VRAM to update a frame.
I would like to know how it's done (I'll need to check the github), because it's equally wonderful if it's done with a bitmapped mode or a tile based one...
I would like to know how it's done (I'll need to check the github), because it's equally wonderful if it's done with a bitmapped mode or a tile based one...
At a very quick glance at the source, it seems to be using mode 2, so it seems to be tile based. It also seems to be using an enormous unrolled loop to read offsets into DE, add those to HL, read the result into A, then output that to the VDP.
I would like to know how it's done (I'll need to check the github), because it's equally wonderful if it's done with a bitmapped mode or a tile based one...
It's for MSX1 so you can load it into Emulicious and investigate it there. Being for MSX1 also means that it uses the "legacy modes".
It seems it uses Graphics 2 because of a need to change data on a per-line basis, but the horizontal resolution is pretty coarse, it looks like 64 cells of 1x4 solid color across a scan line.
Since we have a scan line counter and interrupts, maybe a SMS approach could be using the TMS9918 multi-color mode?
If you had a static PN (768 bytes) and four PGs (8K) dynamically updated you could cycle through the PGs every four scanlines. Thus the pixel mapping would be:
PG #0 : Color data for line 0 and 4 for rows 0-23
PG #1 : Color data for line 1 and 5 for rows 0-23
PG #2 : Color data for line 2 and 6 for rows 0-23
PG #3 : Color data for line 3 and 7 for rows 0-23
I guess the problem is that the data isn't linear so you'd have to set the VRAM address a lot before writing data. That could hurt performance.
Taking a look at the tool that seems responsible for generating the lookup tables used by the demo (test_track_LUT.cc), it seems that, for every horizontal and vertical "subdivision" (lower two bits of the players' coordinates) and for every possible angle, there's a list of which offsets on the map "texture" will be used for which "pixel" on screen.
I’m not sure how much I can agree that modern hardware using the host system as a kind of display adaptor is really a great technical achievement. However in this case it seems it’s simple enough to be supportable by the flash cart FPGAs similar to other modern “super FX” style enhancements, and it does seem to operate as a support chip for the main program rather than a system in itself.
Meanwhile, I still want to write a Master System native raytracer, targeting many hours per frame...