R0ger

Good job ! Feel free to join Atari chiptunes discord server for some real-time feedback and help: https://discord.gg/JXPXFqq

That's actually simple. I can't attach 7z on this forum

Did a little test. It's simple XEX streaming, only works in emulator. Tested with Altirra. You need pal artifacting, pal machine, frame blending recommended on 60fps screens. The source framerate is 24, this is 25 with no conversion, so it's slightly faster. gangam-style.zip

Btw. I was experimenting with the same approach using mode 4. 4 hues (I use RGBY), 6 brightness levels. The 6th brightness level is PMG underlay. Of course I can only use 4 brightness levels per character, so I decide whether the characters is dark, medium, bright, or what I call 'high contrast'. I don't do anything special for the hues, first I can't switch so many palette entries between lines, second it's not needed really. This gives me 4x6 = 24 colors. It's not entirely bad. But I can also interlace this. I get 10 hues using different combinations, and 11 brightness levels. All that with 160x100 square pixels resolution. And I use the interlace to get more colors, not better resolution as usual. I only flicker 2 brightness levels which are already close together, so it doesn't flicker as bad as you might expect. Here are some examples. 24 colors, no flickering: 110 colors, flickering: I made short lecture about this n Atariada, you can see it here (in English, you've been warned). I suggest skipping toward the end for more examples. Question of course is .. could it be combined with this kind of video playback ? It uses extensive DLI, almost no cycle left. It's character mode and it uses all PMG. It does work with just the character mode, or with just 4 levels of brigthness, but every level counts. lambo.4x6.xex lambo.10x11F.xex

It works like this: 1: 16 hues of lowest brightness 2: 16 grays 3: 16 hues of lowest brightness 4: 16 grays The first line is what you perceive as black line. Basically you provide hue in one line, brightness in second.

Indeed. But that's the thing. 1 frame refresh is standard since 2600 times. It's the only way to do it on 2600. But for most games, it's just pointless. And once you aim for 3 frames refresh, soft sprites are no longer a problem. And I think game like IK could be designed so you don't need shifting, the way Wratchild suggested. That would make everything so much easier. Which means you could either do it faster, or do much more stuff in the same time.

No, they are preshifted. It's done on the fly, using those tables. It seems shift and mirror is done first, and result is stored in extra buffer, one for each character. Then these buffers are merged into final charset.

It looks like it, but it's not the case. If you try to make the shortest possible step, it will indeed move you 4 pixels most of the time. But not always .. if you will do it back and forth several times, you will end up on different positions inside byte. I didn't find code doing it, I just found the tables (since it's clear how they should look). Other processing they must do is merging the front and back characters together. PMG is used for coloring the second player. They use clever trick for that. The player doing attack last is in the front. So sometimes it's player one, and sometimes player two. So theoretically the PMG has to be sometimes masked by the player in front. But that's not how they do it. The PMG is used always for the player in the front, unmasked. Just the colors are swapped when needed.

By scrolling I mean shifting bits inside bytes.

The sprites .. they only move in X direction. The characters are broken into rows of characters. With 1D scrolling, you need extra character on each row to accommodate the extra pixels. But that's it. If it was 2D movement, it would be much more complicated.

I did some debugging on Internation karate .. and there is nothing special in there really. The sprites are stored unscrolled, unmirrored. Scrolling and mirroring is done with tables. It uses character mode, which means it doesn't have to process the empty areas in large sprites. Since the game uses only 1D scrolling, there is basically no code penalty over linear VRAM. Character processing code uses expanded loops of course. Btw. maximum speed of the game is refresh per 3 frames. Which in my experience is quite enough to do a lot of processing, while still giving fluent experience. Also game, which relies more on animations, rather than objects moving across the screen, will not benefit from higher refresh rate .. it would need unreasonable amount of animation phases.

Wow, so it actually has an ending !?

I would go for soft sprites. Double dragon type game doesn't really have to 1 frame refresh. You can then use PMG as underlay for adding more color, the way International karate does it.

Problem is, the game has to be built from the ground up to use networking. Mainly it really complicates DLIs. It's something veterans have trouble with, certainly not a feature for your first game. 2 players with 2 joysticks on one screen will be more than enough. And more than this bunch deserves

Multiplayer over cable, basically ..

It's not much, but what there is looks good !

It's not even related to any Antic mode. The format is the same I need for the game. It's 1 byte per tile, there are 16 basic tiles, where individual bits define what corner of the tile is occupied, and tiles above that are 'cosmetic' and can only appear in the middle of the island, the contain the houses and other details. The game itself uses Antic mode E (ie. non-character). The fact I use 4x4 pixel tiles and the logical limitations prevent me from using any other tile map software. Also I would most likely need to convert the data anyway. My map editor also uses RLE compression when saving. By creating the whole editor from scratch, I don't have to do the conversion, I can adapt it to anything I need. And editor like this is basically the 'Paint' procedure, which can display the data structure on screen. Then you add some mouse handling, and that's it. There's nothing special about it. It is interesting topic though. Every project needs tools like this. Even graphics conversion. In every project I make, there is something special, I didn't use before. I reuse the old tools, but I modify them substantially for the new project. I know many people use existing software for this, I don't understand how they do it. I also use VB6 for prototyping .. like testing if some math will work, and how to convert it to integer arithmetic, or if the graphics would look good while moving, or how the controls feel. All much easier on modern computer. So these tools are often just extension of the prototype, it was the case with Sails of doom map editor.

I write all tools for every project in VB6. I wouldn't use existing level editor, I'm sure it would miss features I need. Like map editor for my Sails of Doom. It uses 4x4 tiles, and complicated limitations to tile placement. Sure it doesn't have any fancy features, and it's controlled by key shortcuts only I know. But it does the job.

Btw. after my Road intro I'm against widescreen modes. Some modern TVs will analyze the signal, decide it is actual widescreen TV signal, and will show it all, including areas which shouldn't be visible, like the trash on the right border. IMHO the optimal way is 40 characters, black border.

No kidding. I never thought of that !

Damn I clicked on the Fractalus video, and of course I exactly hit the spot with the monster.

Ok. Now I'm even more confused about fluffy controls. But listing the games is good approach to define the term I guess.

Well anyway, this port showed beyond doubt, that porting Nintento games is nonsense. I suggest make something original, than you can tune it to Atari hardware from the start.

I don't understand what they were thinking. Nintendo is known for being very strict about copyrights.

Just my 2 cents. SID is miles better than POKEY. It's actual music instrument. POKEY is keyboard driver. Yes, it can play music. And thanks to many talented authors, it can play very nice music. But it's always fighting the chip. One more channel can't overweight the limitations, like 8 bit frequencies, non linear volume mixing, and straight out lack of features. You could also say, that POKEY has two 16 bit channels, while SID has three. For me, fighting the chip is the fun. It's just sometimes I feel focusing just on making the music might be fun too