Streemerz NES port

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic

Streemerz NES port
by thefox on 2012-03-09 (#91095)

EDIT (2012-10-10): Project has been completed, download the ROM from www.fauxgame.com.

---

Continuing from here...

To recap, this project is about making a NES port of the "NES-lookalike" Flash game called Streemerz, which itself is based on one of the games in the Action 52 multicart. See the thread linked above for more details.

This project was started about a year ago but was put on hiatus not long after that because of difficulty obtaining the level assets, and not being interested in doing a ton of manual work.

Lately it has been picking up steam again thanks to help from other members of this forum.

I'll be using this thread as a sort of project blog from now on. Next item on the TODO list is to convert the binary level dumps from the Flash game to XML format for Tiled.

Here's a screenshot of an old prototype written in C:

by Grumskiz on 2012-03-09 (#91100)

Looks great!
Will the maps scroll? As far as I remember there was an issue with the map size, am I correct?
So were you able to shrink them without altering them completely or will they scroll even though they're originally intended to be "single screen"?

by tepples on 2012-03-09 (#91101)

The NES picture is 256x240, with a few scanlines cut off the top (up to 16) and bottom (up to 11) by the TV. StreEmerZ (Flash version) uses maps of 320x240 pixels with no overscan. There are two ways to handle this: A. draw the map onto 320 pixels of a 512x240 pixel vertical mirrored plane and scroll back and forth, or B. redraw all the maps to be 256 pixels wide. Lode Runner does a mix of both: it scrolls horizontally, and the maps are slightly cut down vertically. I'd prefer B, but if one can make a strong case that A improves the port, so be it.

by thefox on 2012-03-09 (#91105)

Grumskiz wrote:
Looks great!
Will the maps scroll? As far as I remember there was an issue with the map size, am I correct?
So were you able to shrink them without altering them completely or will they scroll even though they're originally intended to be "single screen"?

Currently they scroll horizontally. If they can be shrinked down without changing the level designs too much, I'm all for that, but it's not top priority right now. The nice thing is it should be pretty easy to switch between the two (if/when the levels have been re-designed) without having to touch any of the engine code.

Like tepples said, there's also the problem with vertical resolution and overscan on some TVs, which might affect some levels. Again this isn't something I'm going to be worrying about too much right now.

by thefox on 2012-03-10 (#91135)

Got the binary maps converted to Tiled XML format:

Not all of the binary files are maps, some of them contain objects for the maps and some contain dialogue. Now the problem is finding out which object list belongs to which map... After I figure that out, I'm going to write some more code to get the objects to show up in Tiled as well.

by Bananmos on 2012-03-10 (#91137)

I would vote for horizontal scrolling rather than conversion, just to keep the experience as close as possible to the original.

But ultimately, I'd enjoy any option that would let us see this NES port completed :)

by thefox on 2012-03-10 (#91138)

I think I found a way to assign the original names to the dumped assets.

Dwedit, what software did you use to dump the images and the audios? If you can dump them with the Flash tag header still in them, I can get the tag ID from the beginning of the file and use it to assign them a name that's used to reference the asset in the source. There's a symbol table (consisting of tag IDs and their names) at offset 0x5E3E46 in the unpacked SWF file.

EDIT: Or if you can dump them so that the filename contains the tag ID, that would be fine as well...

EDIT: Here are the tag IDs and the symbols which reference them:

Code:
{2: ['MainGame_embedded_font_string'],
3: ['GamePreTitle_START_SOUND'],
4: ['SoundManager_MUSIC_TITLE'],
5: ['SoundManager_MUSIC_ORIGINAL'],
6: ['SoundManager_MUSIC_CHEETAH'],
7: ['SoundManager_MUSIC_MUSIC2'],
8: ['SoundManager_MUSIC_MUSIC'],
9: ['GameTitle_STEP2'],
10: ['GameTitle_STEP1'],
11: ['GameTitle_MONEY_JINGLE'],
12: ['GameTitle_METAL_SOUND'],
13: ['HowToPlay_START_SOUND'],
14: ['GamePlay_PAUSE'],
15: ['GamePlay_THUNDER'],
16: ['Player_GRAPPLE'],
17: ['Player_REEL'],
18: ['Player_FLIP'],
19: ['Player_STEP1'],
20: ['Player_RESPAWN'],
21: ['Player_JUMP'],
22: ['Player_STEP2'],
23: ['Player_TRACT'],
24: ['Player_DIE'],
25: ['Player_METAL_SOUND'],
26: ['Player_CAST'],
27: ['Player_LAND'],
28: ['Trap_TRAP'],
29: ['Candle_FLAME'],
30: ['Candle_FLAME_DIE'],
31: ['Door_DOOR'],
32: ['Breakable_BREAK'],
33: ['HUD_Textbox_TEXT'],
34: ['HUD_Textbox_M_EXPLODE'],
35: ['CheckPoint_CHECK'],
36: ['FlyClown_EXPLODE'],
37: ['PieThrower_THROW'],
38: ['MasterY_TRACT'],
39: ['MasterY_JUMP'],
40: ['MasterY_RESPAWN'],
41: ['MasterY_LAND'],
42: ['MasterY_METAL_SOUND'],
43: ['MasterY_REEL'],
44: ['MasterY_CAST'],
45: ['MasterY_DIE'],
46: ['MasterY_GRAPPLE'],
47: ['MasterY_FLIP'],
48: ['Thunder_THUNDER'],
49: ['Money_MONEY_JINGLE'],
50: ['Clown_EXPLODE'],
51: ['GameVEnding_TEXT'],
52: ['GameEnding_TEXT'],
53: ['Explosion_EXPLODE'],
54: ['EscapePodGFX_POD'],
55: ['Metal_METAL'],
56: ['VLevelList_LEVEL1_EFile'],
57: ['LevelList_COMMS6_EFile',
'JLevelList_COMMS6_EFile',
'EasyLevelList_COMMS6_EFile'],
58: ['JLevelList_LEVEL4_EFile', 'LevelList_LEVEL4_EFile'],
59: ['ScriptList_COMMS4_File'],
60: ['JLevelList_LEVEL4_MFile', 'LevelList_LEVEL4_MFile'],
61: ['ScriptList_ESCAPE_File'],
62: ['ScriptList_Y_ENDING_File'],
63: ['GameTitle_SELECT'],
64: ['ScriptList_V_002_File'],
65: ['Player_PLAYER', 'MasterY_PLAYER'],
66: ['ScriptList_Y_FUU_File'],
67: ['EasyLevelList_COMMS5_MFile',
'JLevelList_COMMS7_MFile',
'JLevelList_COMMS5_MFile',
'EasyLevelList_COMMS6_MFile',
'LevelList_COMMS7_MFile',
'VLevelList_COMMS5_MFile',
'VLevelList_COMMS6_MFile',
'LevelList_COMMS6_MFile',
'JLevelList_COMMS6_MFile',
'LevelList_COMMS5_MFile',
'EasyLevelList_COMMS7_MFile',
'VLevelList_COMMS7_MFile'],
68: ['ScriptList_Y_VENI_File'],
69: ['ScriptList_V_007_File'],
70: ['LevelList_COMMS3_MFile',
'EasyLevelList_COMMS3_MFile',
'JLevelList_COMMS3_MFile',
'VLevelList_COMMS3_MFile'],
71: ['GameTitle_TITLE_GRAPHIC', 'GamePreTitle_TITLE_GRAPHIC'],
72: ['EasyLevelList_LEVEL4_EFile'],
73: ['VLevelList_COMMS2_EFile'],
74: ['ScriptList_Y_B16_File'],
75: ['JLevelList_LEVEL3_EFile', 'LevelList_LEVEL3_EFile'],
76: ['JLevelList_LEVEL7_EFile', 'LevelList_LEVEL7_EFile'],
77: ['VLevelList_COMMS7_EFile'],
78: ['ScriptList_DEPRESSURE_File'],
79: ['EasyLevelList_COMMS2_MFile',
'LevelList_COMMS2_MFile',
'VLevelList_COMMS2_MFile',
'JLevelList_COMMS2_MFile'],
80: ['MasterY_LINE', 'Player_LINE'],
81: ['HowToPlay_HELP_1'],
82: ['HowToPlay_HELP_2'],
83: ['PieThrower_CLOWN'],
84: ['EasyLevelList_LEVEL3_MFile',
'JLevelList_LEVEL3_MFile',
'LevelList_LEVEL3_MFile'],
85: ['ScriptList_POISON_LOCATION_File'],
86: ['LevelList_LEVEL5_MFile',
'EasyLevelList_LEVEL5_MFile',
'JLevelList_LEVEL5_MFile'],
87: ['JLevelList_COMMS4_EFile',
'EasyLevelList_COMMS4_EFile',
'LevelList_COMMS4_EFile'],
88: ['ScriptList_VINTRO_File'],
89: ['ScriptList_Y_MONEY_File'],
90: ['ScriptList_VENI_INTRO_File'],
91: ['ScriptList_Y_POISON_DEATH_File'],
92: ['ScriptList_V_DEFLECT_File'],
93: ['HUD_Textbox_TEXTBOX'],
94: ['ScriptList_V_PIE_File'],
95: ['ScriptList_ENDRACE_File'],
96: ['JLevelList_LEVEL6_MFile', 'LevelList_LEVEL6_MFile'],
97: ['JLevelList_COMMS5_EFile',
'LevelList_COMMS5_EFile',
'EasyLevelList_COMMS5_EFile'],
98: ['ScriptList_POISON_DEATH_File'],
99: ['SuperPlayer_SUPER_PLAYER'],
100: ['ScriptList_V_006_File'],
101: ['ScriptList_VENI_File'],
102: ['Pie_SPRITEMAP'],
103: ['Explosion_EXPLOSION'],
104: ['ScriptList_Y_B9_File'],
105: ['LevelList_LEVEL6_EFile', 'JLevelList_LEVEL6_EFile'],
106: ['ScriptList_BALL_File'],
107: ['ScriptList_B16_File'],
108: ['VLevelList_LEVEL5_MFile'],
109: ['ScriptList_Y_POISON_LOCATION_File'],
110: ['SuperLevelList_LEVEL1_MFile'],
111: ['LevelList_COMMS1_EFile',
'JLevelList_COMMS1_EFile',
'EasyLevelList_COMMS1_EFile'],
112: ['ScriptList_Y_WEAK_File'],
113: ['JLevelList_LEVEL5_EFile', 'LevelList_LEVEL5_EFile'],
114: ['ScriptList_COMMS3_File'],
115: ['ScriptList_Y_ESCAPE_WAY_File'],
116: ['VLevelList_COMMS4_EFile'],
117: ['MasterY_MASTERY', 'JPlayer_J_PLAYER'],
118: ['ScriptList_Y_GETHIM_File'],
119: ['GrappleHook_GRAPPLEHOOK'],
120: ['EasyLevelList_COMMS7_EFile',
'LevelList_COMMS7_EFile',
'JLevelList_COMMS7_EFile'],
121: ['ScriptList_Y_COMMS2_File'],
122: ['ScriptList_PIE_File'],
123: ['VLevelList_COMMS4_MFile',
'JLevelList_COMMS4_MFile',
'LevelList_COMMS4_MFile',
'EasyLevelList_COMMS4_MFile'],
124: ['ScriptList_Y_PIE_File'],
125: ['LevelList_LEVEL1_MFile', 'JLevelList_LEVEL1_MFile'],
126: ['SuperLevelList_LEVEL1_EFile'],
127: ['VLevelList_LEVEL6_MFile'],
128: ['JLevelList_COMMS3_EFile',
'EasyLevelList_COMMS3_EFile',
'LevelList_COMMS3_EFile'],
129: ['GrappleHook_GRAPPLEHOOK_MASK', 'Ball_GRAPPLEHOOK_MASK'],
130: ['ScriptList_GETHIM_File'],
131: ['VLevelList_COMMS5_EFile'],
132: ['LevelList_LEVEL2_EFile', 'JLevelList_LEVEL2_EFile'],
133: ['FlyClown_CLOWN'],
134: ['ScriptList_METAL_File'],
135: ['Money_MONEY'],
136: ['JLevelList_COMMS2_EFile',
'LevelList_COMMS2_EFile',
'EasyLevelList_COMMS2_EFile'],
137: ['ScriptList_ENDING_File'],
138: ['net.flashpunk.graphics.Text__FONT_DEFAULT'],
139: ['EasyLevelList_LEVEL6_EFile'],
140: ['Smoke_SMOKE'],
141: ['ScriptList_Y_INTRO_File'],
142: ['VLevelList_LEVEL7_EFile'],
143: ['ScriptList_V_END_File'],
144: ['LevelList_LEVEL7_MFile', 'JLevelList_LEVEL7_MFile'],
145: ['ScriptList_MEASURE_File'],
146: ['ScriptList_Y_BALL_File'],
147: ['BlueBall_BLUE_BALL'],
148: ['LevelList_LEVEL1_EFile', 'JLevelList_LEVEL1_EFile'],
149: ['VLevelList_LEVEL7_MFile'],
150: ['ScriptList_FUU_File'],
151: ['ScriptList_V_009_File'],
152: ['ScriptList_Y_COMMS3_File'],
153: ['Candle_CANDLE'],
154: ['VLevelList_LEVEL2_MFile'],
155: ['EasyLevelList_LEVEL6_MFile'],
156: ['VLevelList_COMMS3_EFile'],
157: ['GameTitle_TITLE_LOGO', 'GamePreTitle_TITLE_LOGO'],
158: ['ScriptList_Y_COMMS6_File'],
159: ['VLevelList_LEVEL3_EFile'],
160: ['HUD_DEATHFACE'],
161: ['VLevelList_COMMS1_MFile',
'EasyLevelList_COMMS1_MFile',
'JLevelList_COMMS1_MFile',
'LevelList_COMMS1_MFile'],
162: ['VPlayer_V_PLAYER'],
163: ['VLevelList_LEVEL4_MFile'],
164: ['ScriptList_V_010_File'],
165: ['ScriptList_V_001_File'],
166: ['EasyLevelList_LEVEL1_MFile'],
167: ['ScriptList_V_004_File'],
168: ['VLevelList_COMMS6_EFile'],
169: ['ScriptList_V_008_File'],
170: ['Main_MG_Logo'],
171: ['ScriptList_ESCAPE_WAY_File'],
172: ['EasyLevelList_LEVEL2_EFile'],
173: ['Trap_TRAP_SPRITE'],
174: ['VLevelList_LEVEL4_EFile'],
175: ['ScriptList_MONEY_File'],
176: ['ScriptList_Y_COMMS4_File'],
177: ['ScriptList_Y_BOMBOFF_File'],
178: ['ScriptList_V_011_File'],
179: ['ScriptList_EXIT_File'],
180: ['EasyLevelList_LEVEL2_MFile'],
181: ['EasyLevelList_LEVEL5_EFile'],
182: ['EasyLevelList_LEVEL4_MFile'],
183: ['Hook_HOOK'],
184: ['EasyLevelList_LEVEL3_EFile'],
185: ['ScriptList_CLOWN_File'],
186: ['ScriptList_BOMBOFF_File'],
187: ['HUD_Textbox_FACES'],
188: ['EndingBG_BG'],
189: ['ScriptList_COMMS6_File'],
190: ['ScriptList_COMMS2_File'],
191: ['GhostPlayer_PLAYER'],
192: ['Clown_CLOWN'],
193: ['VLevelList_LEVEL6_EFile'],
194: ['EasyLevelList_LEVEL7_MFile'],
195: ['Breakable_BREAKABLE'],
196: ['VLevelList_LEVEL1_MFile'],
197: ['ScriptList_END_File'],
198: ['VLevelList_LEVEL5_EFile'],
199: ['CheckPoint_POINT'],
200: ['ScriptList_INTRO_File'],
201: ['VLevelList_LEVEL2_EFile'],
202: ['ScriptList_WEAK_File'],
203: ['LevelList_LEVEL2_MFile', 'JLevelList_LEVEL2_MFile'],
204: ['ScriptList_Y_ESCAPE_File'],
205: ['EasyLevelList_LEVEL1_EFile'],
206: ['Deflector_SPRITE'],
207: ['ScriptList_Y_DEPRESSURE_File'],
208: ['EasyLevelList_LEVEL7_EFile'],
209: ['Level_TILES'],
210: ['VLevelList_COMMS1_EFile'],
211: ['VLevelList_LEVEL3_MFile'],
212: ['Main_MG_Logo_dataClass'],
213: ['Ball_BALL'],
214: ['ScriptList_B9_File'],
215: ['ScriptList_V_003_File'],
216: ['ScriptList_V_005_File'],
217: ['ScriptList_Y_VENI_INTRO_File'],
218: ['ScriptList_Y_CLOWN_File']}

by slobu on 2012-03-10 (#91155)

Have you already tried to contact the original author of Streemerz? I'm sure Arthur Lee would be honored to help port Streemerz back to the NES.

http://www.superfundungeonrun.com

by tepples on 2012-03-10 (#91160)

In this post, thefox wrote:
I actually started working on this after okaying it with the original author first. He sent me the player sprites but hasn't responded to my latest message where I asked for more assets (levels...).

The port got hung up on this for a year until we finally figured out two ways to extract the maps. What finally got us off our collective asses may have been a multicart project that I had started working on early in the year.

by tokumaru on 2012-03-10 (#91168)

slobu wrote:
Have you already tried to contact the original author of Streemerz? I'm sure Arthur Lee would be honored to help port Streemerz back to the NES.

If I'm not mistaken, he was already contacted and didn't show much interest. I could be wrong though.

by thefox on 2012-03-10 (#91169)

slobu wrote:
Have you already tried to contact the original author of Streemerz? I'm sure Arthur Lee would be honored to help port Streemerz back to the NES.

http://www.superfundungeonrun.com

Yes I contacted him the very first thing when I started the project, he never replied to my query about the level assets. I don't blame him though, if a random guy came to me asking for similar stuff, I probably wouldn't give the project a high chance of getting finished, and consequently wouldn't want to waste my time explaining all the inner workings of the engine. At this point it doesn't even matter, most of the stuff has been RE'd (and it has been kind of fun, actually).

I'm really glad we found a way to extract the original binary maps, figuring out all the small details about object placement, events, differences in map per difficulty levels etc would have been a ton of work. Also since I now have all the original dialogue files etc it's much easier to make sure that nothing gets missed...

by Nioreh on 2012-03-10 (#91171)

This is great. I also vote for horizontal scrolling to keep the levels as close to the "original" as possible. (unless it becomes too much of a distraction)

I died 69 times on easy in the flash game

Really hope you finish taking this cool Streamers remake to the NES. Imagine if all of the Action 52 games were as good as this, man what a bargain it would have been.

by thefox on 2012-03-11 (#91218)

thefox wrote:
After I figure that out, I'm going to write some more code to get the objects to show up in Tiled as well.

Done:

There's going to be some redundancy in the map files when converted like this because the original game has separate map and entity (aka object) files. This doesn't really matter however, because the maps and entities can be globally optimized when exporting them back to NES.

Next I'm going to start thinking about converting some of the entities (like the purple metal blocks and the immobile balls) to tiles.

by Dwedit on 2012-03-11 (#91221)

With proper compression (and maybe WRAM), would this fit into 32k?

by tepples on 2012-03-11 (#91222)

I don't necessarily see why WRAM would be needed for decompression; each 320x240 pixel screen is 300 metatiles. There are about 62 screens in the map pieced together from screenshots, and I'd bet each can be compressed 2:1.

by thefox on 2012-03-11 (#91227)

32K is probably within the realm of possibilities, assuming no additional content is added, but like I've said in the past, now is not the time to worry about that. The main goal is to get it finished, if it comes out close enough to the NROM limitations, then we can see if it's possible to squeeze it in.

by tepples on 2012-03-11 (#91232)

Yeah, premature optimization is up there with love of money as a root of all kinds of evil. But even if it takes 64 or 128 KiB, I think I can still figure out how to include a bigger mapper 34 game in a multicart.

by thefox on 2012-03-13 (#91310)

The level converter now generates a background color layer (the game has a per screen modifiable background color, in this case brown):

The background color modification is also used for the thunder effect (screen flashes red momentarily). Some of the levels have black silhouettes/shadows in some parts with thunder, so they show through during the red flash:

This can't really be done by changing the background color on the NES, because it makes more sense to reserve it for black since it's used by most tiles. I could reserve 2 colors out of a palette set for it, but not sure if it's worth it given how hard it is to fit the palette limitations as it is... Or I could try just changing the background color (changing the outlines of tiles etc at the same time), it wouldn't look perfect but might be OK.

Need to start thinking about the palette next. I may write a tool to help in figuring out all the color combos used in every screen and try to go from there...

by thefox on 2012-03-15 (#91355)

I wrote a tool to generate a complete, merged tileset out of all the layers of all the maps, here's the result:

Some of the entities have also been merged with the background (balls, hooks and deflectors (the vertical lines)). Pure red is for areas with thunder.

Balls currently have a transparent background, but because of palette limitations on the NES I'm going to have to make their background black. Same goes for hooks and deflectors. There are also two similar blueish palette sets that the game uses (one with grey, the other with light blue) that I'm going to merge. Should be able to get it down to 4 background palettes then with some minor changes.

by thefox on 2012-03-17 (#91425)

I think I have the palette pretty much figured out. Had to make some compromises but nothing too drastic. Only bigger problem right now is that the balls and hooks look quite ugly with black background when they're on top of green wall. There are a bunch of possible solutions for this but I'm going to leave that for later.

I wrote a (yet another) small tool to check that all the screens of all the levels comply with the palette limitations. They seem to be OK.

There are 100 metatiles in the tileset right now. Next I need to figure out which one of them each screen uses, how to divide them to sensible groups and how many unique 8x8 tiles there are.

by thefox on 2012-03-18 (#91471)

thefox wrote:
how many unique 8x8 tiles there are.

Comes down to around 291 tiles:

by tepples on 2012-03-18 (#91479)

There are a few ways to go about working around this:
What happens if you try to make two tilesets, one with just those tiles used in communication rooms and another with tiles used outside communication rooms? You'll need a full alphabet in the communication rooms anyway.
Use CHR RAM, and allow only a couple of the floor number tiles (roughly $C9 through $F3 in the tile set you posted) to show through.
Find a way to rearrange palettes to eliminate the nearly duplicate tiles with dots in the corners.

by thefox on 2012-03-18 (#91496)

tepples wrote:
There are a few ways to go about working around this:
What happens if you try to make two tilesets, one with just those tiles used in communication rooms and another with tiles used outside communication rooms? You'll need a full alphabet in the communication rooms anyway.
Use CHR RAM, and allow only a couple of the floor number tiles (roughly $C9 through $F3 in the tile set you posted) to show through.
Find a way to rearrange palettes to eliminate the nearly duplicate tiles with dots in the corners.

Yeah I think I'm going to use CHR-RAM. I could do 2-3 different metatile sets, switch based on the screen and upload a different tileset each time the screen changes. I also need couple of tiles for the textbox font and borders, but I might be able to fit those in the other CHR bank and switch the background bank on the fly. We'll see, but everything's looking pretty good so far.

by thefox on 2012-03-20 (#91583)

I wrote some C (CC65) code to test the screen loading -- it works! I now have all the data I need to load all of the screens in the original game. No objects or collision data yet, though.

Here's a pointless screenshot of a level loaded from the (more or less) automatically generated data:

(Palette may still change.)

Soon it'll be the time to start writing some 6502 asm.

by thefox on 2012-03-24 (#91769)

I extended the screen loader test to make it possible to flip between different screens and scroll horizontally using the controller, everything seems to be working as it should. Next I'll probably export the collision data, as well as a "grappleable"/death/etc flags for each metatile.

Map data currently takes 44KB (metatile data not included). ZIP brings it down to about 7KB (16%), but this is for a binary file containing all the screens, in the actual game I need to access them individually. It seems that screen by screen the compression ratio with ZIP tends to be around 33%.

Can anybody recommend some solution for packing and unpacking the data (preferably with the unpacker already implemented in 6502)? Has anybody used pucrunch on an NES project?

by mic_ on 2012-03-24 (#91774)

Quote:
Can anybody recommend some solution for packing and unpacking the data (preferably with the unpacker already implemented in 6502)?

I've got an apLib decruncher for the 6502: http://jiggawatt.org/badc0de/decrunch/aplib_decrunch_6502.asm

by thefox on 2012-03-24 (#91775)

mic_ wrote:
Quote:
Can anybody recommend some solution for packing and unpacking the data (preferably with the unpacker already implemented in 6502)?

I've got an apLib decruncher for the 6502: http://jiggawatt.org/badc0de/decrunch/aplib_decrunch_6502.asm

I'll keep that in mind. I tried using the aPLib packer on all the levels (individually) and got a total compression ratio of 38.6%. That should do.

by thefox on 2012-03-25 (#91801)

thefox wrote:
Next I'll probably export the collision data, as well as a "grappleable"/death/etc flags for each metatile.

Done. I also changed the palette around a bit.

I'm getting sick of tool coding. It's pretty ridiculous that even the simplest things take hours upon hours to implement. Oh well, NES happens.

Now I can start moving the level stuff over to the asm engine. Then I'll start on the object/entity/sprite stuff.

by tokumaru on 2012-03-25 (#91808)

I guess that coding tools really is a part of making NES games, unless you are making simple games where data doesn't need to be encoded in very specific ways. This case in particular is a bit different though, since you need to do a lot of conversions from the formats that were used in the original game.

Anyway, it's cool that this game will finally be playable in the console where it belongs! =)

by thefox on 2012-03-27 (#91867)

Anybody know of a (free) Flash decompiler that could be used to get the ActionScript files from the SWF? The program I'm currently using, Sothink SWF Decompiler, seems to work pretty well, but the trial version doesn't allow saving the script files (or copying the text from them), and my trial is up in 10 days. The decompiled scripts will be very useful in fine tuning the physics and stuff.

I moved the level stuff over to my asm engine, it went surprisingly smoothly. I have the sprite from Shatterhand bouncing around the screens, collisions also work as expected.

Next I need to write a routine to load an arbitrary screen (I think I'm going to use banking for now and keep the ~40K of levels uncompressed), as well as make sure that the collision against the screen above the current one works correctly. Then I have to export the levels (each of which are just a list of screens that the level uses), and then also generate a list of levels for the different game modes.

After that it's time to start thinking about how to export the objects. Some of the objects I'll convert to level/screen properties.

by Dwedit on 2012-03-27 (#91876)

I tried HP Swfscan, and couldn't get any relevant scripts out of the game. Just useless crap like the preloader. I don't think there are any fully working AS3 decompilers yet.

Even SWFMILL can't get a correct disassembly.

I do know there are multiple DoAbcDefine tags, and that throws off some decomplers.

I think it's probably time to break out the video recorder (camstudio), record some gameplay, and play it back frame-by-frame to get a good idea of what's going on.

by tokumaru on 2012-03-27 (#91878)

I've had some luck with this in the past: https://sites.google.com/site/as3extractor/

Not that a pirate portable version of Sothink SWF Decompiler is terribly hard to find. I don't really mean to encourage piracy, but since this is a one time thing that will not result in any financial gain for you, I wouldn't worry so much.

by thefox on 2012-03-27 (#91880)

tokumaru wrote:
I've had some luck with this in the past: https://sites.google.com/site/as3extractor/

Thanks, this seems to work just fine! The extraction feature seems a little bit buggy, if I select stuff using space bar instead of clicking on it, it tells me I haven't selected anything. If I try to extract everything, it chokes on the JSONDecoder class. And after I deselect that class... it chokes on something else. Oh well, I don't need to extract them since I can view them using that program.

EDIT: Spoke too soon, the decompiled code isn't perfect. There's some stuff that's obviously wrong. But then again, so was in the code produced by Sothink SWF Decompiler. Just have to be careful, it should still be useful.

by tokumaru on 2012-03-27 (#91887)

Here's another one you can try: http://code.google.com/p/asdec/

I have these programs hanging around my HD, I don't really remember how good they are. I guess that having options is always good, since one program might do what the other doesn't, so they complement each other.

by thefox on 2012-03-29 (#91957)

I added code to export the object data now. It's only exporting the object type and coordinates right now but it's not too hard to add the additional parameters which some of the object types need.

I also generated the level lists for different game modes and the level information itself (it contains references to each screen and object list that the level uses, as well as global properties like music used in the level).

Level data is almost complete now. Time to start working on the level loader.

tokumaru wrote:
Here's another one you can try: http://code.google.com/p/asdec/

I have these programs hanging around my HD, I don't really remember how good they are. I guess that having options is always good, since one program might do what the other doesn't, so they complement each other.

Yep, this one gave pretty good results as well but some clear errors here as well. But yeah I'm going to cross verify the important stuff with the different programs if something seems shady.

by thefox on 2012-04-01 (#92061)

thefox wrote:
Level data is almost complete now. Time to start working on the level loader.

Level loader done. Screen switcher also works (switches the screen when the player moves up/down). After I implement the doors the level lists will be fully traversable from beginning to end.

There was a minor bump in the road when I noticed that Nintendulator doesn't support CHR-RAM with FME-7 (which is the mapper I'm currently using for testing), but it was pretty easy to modify the Nintendulator mapper sources to fix it.

Next on the TODO list is object support. I think I'll start with The Door. Then I also need to start organizing the sprite tile data to see how much space it'll take, what tiles need to be available at any given time and what palettes they need.

by thefox on 2012-04-01 (#92073)

Doors work now, floated all the way through all of the levels with my Shatterhand sprite until I got stuck in a wall in the last level because my code doesn't handle the level start position properly yet.

by thefox on 2012-04-03 (#92111)

I worked on the sprites today and yesterday. First I copy pasted them all to a single image and started trying to figure out the palette sets. I managed to get a pretty good compromise once again. The "Superb Joe" and Leopardman sprites are problematic though, since some of the colors they use aren't used anywhere else. Technically they can be drawn with the current palette sets, but the sprites would be layered and end up using colors from three different palette sets, so it would probably flicker like hell, especially since Superb Joe and Leopardman need to be on screen simultaneously.

Anyway, next I assigned the palettes to each spritesheet, split them up with Imagemagick, and fed them to my sprite converter. Then I had a bunch of .SPR (the sprite definition) and .CHR files. I took the most common sprites (excluding the Master Y, Dr. Tary, Leopardman and Superb Joe sprites, since those won't be needed simultaneously with the normal player sprite) and combined them to a single .CHR file, optimized the tileset and guess what: it came out at EXACTLY 256 tiles (4KB). Pretty funny coincidence. Here's an image of the tileset in its current state (the tiles are in pseudo random order due to the way the optimizer works):

You may notice that some of the tiles are very similar, but not quite. This is a small problem that occurs when using the sprite converter. It works on individual images, so it doesn't always produce optimal results if the size of the global tileset is a concern. Since it's a genetic algorithm it's also somewhat random in how the sprites are placed (several placements can give the "optimal" result, i.e. the same amount of sprites used).

There are some ways to fix this problem. I could do a first pass, looking for similarities in images, split them up from those areas, then convert, and then recombine them. This should produce a little bit smaller final tileset, maybe with the cost that the metasprites would use some more 8x8 sprites.

Another way to fix it would be to modify the genetic algorithm so that placements which re-use existing tiles (from the global tileset) get some extra "fitness" points. I'm probably not going to bother with that for now.

One way to get more wiggle room in the sprite bank would be of course to upload some of the sprite frames dynamically. Player sprites would be a good candidate for this. They take 8 tiles in the worst case I think, so that would be 8 * 16 bytes to be uploaded per frame, so 128 * 8 = 1024 CPU cycles with the fastest possible code. Considering the only other PPU uploads I need are the OAM and the palette, it should be very much doable.

I should modify my sprite converter (image -> sprite definition) tool to support 8x16 sprites, just to see what kind of results that would give.

...

On another topic, I've been thinking about how to implement the "ghost" in the original game. You see, there's a 5 minute time trial mode in the Flash game. If you complete it, the next time you'll race it you'll see a ghost run of your fastest run, with Leopardman (:)) playing the role of the ghost. Or so I've been told, I haven't actually been able to beat the time trial in 5 minutes yet.

So the problem is how to get 5 minutes worth of controller input / other state data squeezed so that it fits in the WRAM. (I think WRAM is absolutely necessary for this, especially given that there has to be two copies of the data -- one for the current run and one for the fastest run). The data would need to be compressed and decompressed in real time. Compressing just the controller input wouldn't be enough, because we don't have easy access to collision etc data of each screen all the time (and the player might be at a completely different screen than the ghost).

This is certainly not top priority, but it's fun to think about.

by tokumaru on 2012-04-03 (#92113)

thefox wrote:
So the problem is how to get 5 minutes worth of controller input / other state data squeezed so that it fits in the WRAM. (I think WRAM is absolutely necessary for this, especially given that there has to be two copies of the data -- one for the current run and one for the fastest run). The data would need to be compressed and decompressed in real time.

I have routines in my game to record and playback RLE encoded controller data, just tell me if you want me to post them.

Quote:
Compressing just the controller input wouldn't be enough, because we don't have easy access to collision etc data of each screen all the time (and the player might be at a completely different screen than the ghost).

Yeah, this is the real issue. You might have to run two game sessions side by side! I'm sure there will be enough RAM for this (since you're using WRAM), it's the processing time I'm worried about.

Actually I'm not even sure how this can work in the original game... I believe that enemies and objects do not "live" until you enter a room, so how can the ghost enter a screen before you do and interact with the objects in there?

by thefox on 2012-04-03 (#92117)

tokumaru wrote:
I have routines in my game to record and playback RLE encoded controller data, just tell me if you want me to post them.

Yeah sure, that would be nice to have. What kind of compression rate do you get with it generally speaking?

Quote:
Yeah, this is the real issue. You might have to run two game sessions side by side! I'm sure there will be enough RAM for this (since you're using WRAM), it's the processing time I'm worried about.

About WRAM, I was thinking about making the game so that it can work without WRAM, but if WRAM it would have some extra goodies like the ghost thing we're talking about here.

Quote:
Actually I'm not even sure how this can work in the original game... I believe that enemies and objects do not "live" until you enter a room, so how can the ghost enter a screen before you do and interact with the objects in there?

As far as I know, it simply stores the coordinates and the player sprite map index for each frame and probably some other state info for the streemer (this mode is capped at 5 minutes too, so it'll never generate a huge log). I don't think there's any interaction with the objects (and the only object I can think of that would be problematic regarding that is the breakable block, but that's not used in this level... and in any case it would simply just look funny).

I guess the log in the NES version would have to be stored on screen by screen basis (together with some state info for the beginning of the screen). If the player enters the screen while the ghost is in it, it would need to "rewind" so the ghost time matches the players time. If the ghost is not on the same screen as the player, it can simply step to the next frame. I don't know, we'll see if any of this is practical...

by tepples on 2012-04-03 (#92119)

Quote:
Player sprites would be a good candidate for this. They take 8 tiles in the worst case I think, so that would be 8 * 16 bytes to be uploaded per frame, so 128 * 8 = 1024 CPU cycles with the fastest possible code. Considering the only other PPU uploads I need are the OAM and the palette, it should be very much doable.

Yeah, five 32-byte copies from $0100-$019F to the PPU plus an OAM copy from $0200 will easily fit into vblank. If it's good enough for Battletoads... But then you have to make room for copying in the ghost's tile. And you don't need all rooms' sprites loaded at once because you can do like Battle Kid and load only those enemy sprites that a given room uses.

Quote:
So the problem is how to get 5 minutes worth of controller input / other state data squeezed so that it fits in the WRAM. (I think WRAM is absolutely necessary for this, especially given that there has to be two copies of the data -- one for the current run and one for the fastest run).

How many keypresses are there in a typical run? If there are fewer than about 2,000 keypresses, then a single run can fit into 4 KiB. At 300 seconds, that'd be 6 presses per second. Each byte of the controller bytecode would look like this:

7654 3210: ccct tttt
t: number of frames to wait before processing next command
c: command number

Commands:
0: Do nothing
1: Release all buttons
2: Toggle button A
3: Toggle button B
4: Toggle button Up
5: Toggle button Down
6: Toggle button Left
7: Toggle button Right

Another way is to just sample X and Y every few frames, then interpolate at playback time. At 300 seconds and 4 samples per second, that's 2.4 KiB. This even solves tokumaru's problem of the other player interacting with enemies.

Would it be hard to make ghost support and other character support a compile time option?

by tokumaru on 2012-04-03 (#92120)

thefox wrote:
Yeah sure, that would be nice to have. What kind of compression rate do you get with it generally speaking?

I'm afraid that RLE will not be enough enough for 5 minutes... Sorry, but I can't give an idea of how well it compresses, but I really haven't tested it much!

Here's the encoder function:

Code:
;-- SUBROUTINE --------------------------------------------------
;DESCRIPTION:
; Logs the buttom presses in a compressed format to an array that
; can later be used to demonstrate the levels in action.
;INPUT:
; DemoStatus: indicates the operation to execute;
; DemoData: address of the controller data;
; ControllerBuffer: current status of the controller;
;----------------------------------------------------------------
RecordDemo:

;skip if this is not the first frame
lda DemoStatus
cmp #$ff
bne +CompareButtons

;indicate that a demo is being recorded
dec DemoStatus

;initialize the output pointer and start outputting data
lda #$00
sta DemoData+0
lda #$60
sta DemoData+1
bne +WriteNewPair ;always

+CompareButtons:

;branch if the button combination changed
ldy #$01
lda (DemoData), y
cmp ControllerBuffer
bne +AdvancePointer

;increment the number of frames for which the combination is to be used
dey
lda (DemoData), y
beq +AdvancePointer
adc #$00
sta (DemoData), y

;return
rts

+AdvancePointer:

;advance 2 bytes
clc
lda DemoData+0
adc #$02
sta DemoData+0
bcc +WriteNewPair
inc DemoData+1

+WriteNewPair:

;output the duration and the combination of buttons
ldy #$00
lda #$01
sta (DemoData), y
iny
lda ControllerBuffer
sta (DemoData), y

+Done:

;return
rts

And here's the decoder (it's not a function, but it's really simple and easy to figure out):

Code:
;----------------------------------------------------------------
; Demo playback - START
;----------------------------------------------------------------

;skip if the level is not in demo mode
bit DemoStatus
bpl +SkipDemo

;overwrite the controller status, except for the start button
dec DemoCount
bne +
ldy #$01
lda (DemoData), y
sta DemoCount
clc
lda DemoData+0
adc #$02
sta DemoData+0
bcc +
inc DemoData+1
+ ldy #$00
lda ControllerBuffer
and #BUTTON_STRT
ora (DemoData), y
sta ControllerBuffer

+SkipDemo:

;----------------------------------------------------------------
; Demo playback - END
;----------------------------------------------------------------

Quote:
I was thinking about making the game so that it can work without WRAM, but if WRAM it would have some extra goodies like the ghost thing we're talking about here.

It would be really cool if the program could detect the presence of WRAM to enable the goodies, but still work without them on carts without WRAM.

Quote:
I don't think there's any interaction with the objects (and the only object I can think of that would be problematic regarding that is the breakable block, but that's not used in this level... and in any case it would simply just look funny).

So balls and such do not affect the ghost?

by thefox on 2012-04-03 (#92130)

tepples wrote:
How many keypresses are there in a typical run? If there are fewer than about 2,000 keypresses, then a single run can fit into 4 KiB.

Not sure, we'll find out later.

Quote:
Another way is to just sample X and Y every few frames, then interpolate at playback time. At 300 seconds and 4 samples per second, that's 2.4 KiB. This even solves tokumaru's problem of the other player interacting with enemies.

Yeah that might work.

Quote:
Would it be hard to make ghost support and other character support a compile time option?

Shouldn't be too hard, I'll have to see later if there's any benefit to doing that (to have stripped down versions of the game etc).

tokumaru wrote:
So balls and such do not affect the ghost?

Yeah. Well, the effects from those from the previous run are still stored in the log through the X and Y coords, so it doesn't matter. Of course it will look funny with any moving object (which might be out of sync) etc, but there's no way to get around that.

Anyway, I'm going to leave this whole ghost ordeal at rest for now, and start implementing the level objects.

by Bananmos on 2012-04-04 (#92139)

Quote:
You may notice that some of the tiles are very similar, but not quite. This is a small problem that occurs when using the sprite converter. It works on individual images, so it doesn't always produce optimal results if the size of the global tileset is a concern. Since it's a genetic algorithm it's also somewhat random in how the sprites are placed (several placements can give the "optimal" result, i.e. the same amount of sprites used).

There are some ways to fix this problem. I could do a first pass, looking for similarities in images, split them up from those areas, then convert, and then recombine them. This should produce a little bit smaller final tileset, maybe with the cost that the metasprites would use some more 8x8 sprites.

Another way to fix it would be to modify the genetic algorithm so that placements which re-use existing tiles (from the global tileset) get some extra "fitness" points. I'm probably not going to bother with that for now.

I'm having the exact same issues in my sprite optimizing tool Tilificator and have had similar ideas (not implemented yet) on solving it. I'd be interested to know what solution you might implement :)

by mic_ on 2012-04-04 (#92147)

I've used the NeuQuant algorithm frequently for color quantization of images. I wonder if it'd be difficult (and practical) to modify that algorithm so that each neuron represents an 8x8 tile instead of an RGB color - i.e. the output would be the N "best" tiles out of a larger set of tiles.

by thefox on 2012-04-06 (#92228)

Did some tool work once again. This time I wrote a tool to generate an optimized sprite charset, remapped sprite definitions and sprite animation definitions from the sprite definitions and tile data generated by the sprite conversion tool. It can also generate flipped sprite definitions/animations if requested and takes care of hotspots and hitboxes.

As soon as I get around to defining the rest of the animations (the frames used by them and the animation speed) in the Python script, it'll be very easy to start using them in the object implementations. I'm very happy about how this turned out.

by thefox on 2012-04-08 (#92284)

I've started implementing the objects. So far the walking clown, check point, bouncing ball and the door are working (more or less). With all the groundwork that has been laid it should be pretty easy to implement the rest of the objects.

It's hard to decide what to do next. Here's some of the stuff that's still to be done:
Dialogue handling
Rest of the object handlers
Player object handling and dynamic upload of tiles
"AI" handling in the last level
Music and sound effects

by djcouchycouch on 2012-04-09 (#92315)

Whenever I go back and forth, not being able to decide on which task to do next, I make myself pick the first one and just do it.

Or, pick the hardest/most unknown of the bunch. Everything else will seem easier!

by thefox on 2012-04-09 (#92318)

shawnleblanc wrote:
Whenever I go back and forth, not being able to decide on which task to do next, I make myself pick the first one and just do it.

Or, pick the hardest/most unknown of the bunch. Everything else will seem easier!

I decided to continue on the object handlers. Today I implemented the candles, money, blue ball (only used in one screen ), pie throwing clowns and flying clowns. What's left are explosions, breakable blocks and smoke (appears e.g. when a streamer hits a wall). There's also the script object (displays dialogue) and the main villain, which I'll leave for later.

The implemented objects still need some fine tuning though, for example they don't do collision checking with the player yet.

After explosion object is done I think I'll work on the dialogue stuff, just to spice things up. For that I need to reformat the dialogue from the original game so it fits into a smaller text box and convert the faces to tiles. I'll probably use sprites for the faces since they use more than 4 colors, and the original game conveniently hides other sprites anyways whenever the text box shows up.

by thefox on 2012-04-12 (#92403)

I implemented the explosions the other day. I also did most of the work on the breakable blocks: I still need to write code to replace the nametable tiles when the block breaks, but most of the groundwork is done for this as well.

I also started to work on the textbox/dialogue. My sprite converter didn't like the 48x48 face images very much, it takes it a very long time to come up with a solution. It seems it should still be usable though, I just need to somehow take in account the fact that the frames in the talking animations are very similar, so it would be a waste of tiles to convert them separately.

I changed the HUD textbox from grey shade to a blueish/green (like most of the tiles in the levels) because I don't want to mess with midscreen palette switches, especially since I don't plan to use an advanced mappers for this game. I also had to make it smaller so it can't hold as much text as in the original. This means I'll have to reformat the text, which is what I'll start doing next.

by thefox on 2012-04-13 (#92446)

thefox wrote:
This means I'll have to reformat the text, which is what I'll start doing next.

And done. I did it manually, but I may redo it later with MS Word using automatic hyphenation (I didn't think of this option before). Any opinions on this from native English speakers, should I use hyphenation at all? In the original game it's used in some places.

I'm also not sure if I should fix some of the typos in the dialogue ("steemerz" in one place).

Anywho, I exported the dialogue stuff in a 6502 readable format and started working on the text box and text rendering routine in asm. The basic stuff works, I can display any arbitrary piece of dialogue. Still on the TODO list are the face animations, attributes for the text box, restoring the level contents when the text box closes, and prompting for user input.

by Dwedit on 2012-04-13 (#92447)

I think the unintentional typos are okay to fix. But the base must still be set to explod.

by thefox on 2012-04-21 (#92692)

Not much has been happening lately, been super busy with school and other stuff.

However, I did start working on the music today. I received a MIDI of the original song from Gordon McNeil (thanks!) and it has been a tremendous help when trying to make a NESified version of the song. I've got pretty much everything converted in Musetracker already, now I just need to make it sound good. The original song seems to be using stuff like volume envelopes on the triangle channel, and uses more than 4 channels in some parts, so it's not a completely straightforward job.

I've also done the title screen music, it didn't take long.

EDIT: Another thing about the music... I'm contemplating using DPCM samples, or possibly blargg's DPCM saw/triangle/pulse trick to get one extra channel. I'm also a little bit worried about how well the music will work together with the sound effects... Well, we'll see...

by thefox on 2012-05-07 (#93465)

Still not much progress. I started on the tedious job of cleaning up the project (it has got a lot of baggage because I bolted everything on top of my old engine), this is going to take a while. I'm going to have to rethink the memory banking, I'll probably switch to simple 16K mapping using MMC1 (since my current code requires WRAM, but hopefully I can get rid of that later), and later to UxROM.

I also dropped the idea of using DPCM channel for now, hopefully I can make a good 4 channel arrangement of the songs. For now it seems to be working OK.

My motivation hasn't been very high lately unfortunately. Has anybody else noticed that when you lose the "flow", it gets increasingly hard to get back to a project as time passes? Anyway, my summer vacation starts three weeks from now, and I really hope I can bring this project to completion during that time.

by cpow on 2012-05-07 (#93467)

thefox wrote:
My motivation hasn't been very high lately unfortunately. Has anybody else noticed that when you lose the "flow", it gets increasingly hard to get back to a project as time passes?

Yeah I tend to go for months not doing much but making tiny mods and considering giving up all together. Then some Big Idea happens and I get new energy and pound out some serious code for a few months. Lather, rinse, repeat. I consider it the engineer's corollary to a particular feminine cyclical behavior.

I'm enjoying reading about your progress here though...

by djcouchycouch on 2012-05-07 (#93468)

thefox wrote:
My motivation hasn't been very high lately unfortunately. Has anybody else noticed that when you lose the "flow", it gets increasingly hard to get back to a project as time passes? Anyway, my summer vacation starts three weeks from now, and I really hope I can bring this project to completion during that time.

I've been working these past few months on my own project for the Sega Genesis. Knowing that other people are working on their own projects motivates me to work on mine.

The Goplanes thread on SpritesMind:

http://gendev.spritesmind.net/forum/viewtopic.php?t=1090

Latest development video:

http://www.youtube.com/watch?v=Cv9s1H32RSc

by Banshaku on 2012-05-07 (#93489)

thefox wrote:
My motivation hasn't been very high lately unfortunately. Has anybody else noticed that when you lose the "flow", it gets increasingly hard to get back to a project as time passes?

Yes I noticed that. I'm in the same boat. I couldn't touch my project for more than a year, almost 2 and now if I could find time, just thinking about re-studying the code feels quite painful since I must have forgotten most of it. I'm stuck on a bug and just thinking about that is demotivating.

But my child, 5, asked me recently "when is mega man will be able to shoot a bullet?" gave me some motivation So the important part is to find some source of motivation. Now if they could go to sleep earlier, I may be able someday to work on it ^^;;;

by thefox on 2012-05-08 (#93509)

shawnleblanc wrote:
I've been working these past few months on my own project for the Sega Genesis. Knowing that other people are working on their own projects motivates me to work on mine.

Cool project! And I agree, my motivation also stems from all those small things, like replies here on the forum, so thanks for that to everybody.

by Denine on 2012-05-08 (#93510)

Banshaku wrote:
thefox wrote:
My motivation hasn't been very high lately unfortunately. Has anybody else noticed that when you lose the "flow", it gets increasingly hard to get back to a project as time passes?

Yes I noticed that. I'm in the same boat. I couldn't touch my project for more than a year, almost 2 and now if I could find time, just thinking about re-studying the code feels quite painful since I must have forgotten most of it. I'm stuck on a bug and just thinking about that is demotivating.

Hmm, and I thought it's my special trait.I often blame myself for leaving development of my first game, because I'm lazy and a bit of a coward.

Quote:
I've been working these past few months on my own project for the Sega Genesis.
Sweet!

by slobu on 2012-05-08 (#93539)

Denine wrote:
Banshaku wrote:
thefox wrote:
My motivation hasn't been very high lately unfortunately. Has anybody else noticed that when you lose the "flow", it gets increasingly hard to get back to a project as time passes?

Yes I noticed that. I'm in the same boat. I couldn't touch my project for more than a year, almost 2 and now if I could find time, just thinking about re-studying the code feels quite painful since I must have forgotten most of it. I'm stuck on a bug and just thinking about that is demotivating.

Hmm, and I thought it's my special trait.I often blame myself for leaving development of my first game, because I'm lazy and a bit of a coward.

Quote:
I've been working these past few months on my own project for the Sega Genesis.
Sweet!

Programming and non-programming issues can lead to terminal productivity. Ironically, as you distance yourself from the project, it can make you objectively reevaluate the value you get out of it. Figuring out where the logic starts and the depression ends is the hard part.

I personally am about to shelve a Genesis project because my compiler sucks, it's damn hard to get a firm quote on cart production and the music engine is being stupid about importing tracks.

thefox has the advantage that people *get* his project. The Streemerz remake is worthy of porting on gaming merits alone. The fact he's bringing an NES game ported to Windows back to its home is mind-bendlingly awesome!

My hope is that we learn when to stop - but also let ourselves continue. People are rooting for you thefox and Banshaku! Games are art with a canvas of code and colors made of creativity. Homebrewers have the rare gift to multiply fun and excitement by the amount of users who play their work. Finish your project for yourself and know your players will enjoy it in turn: A chain reaction of fun for as long as breath can blow a cart or fingers can fire up an emulator!

Keep up the good work shawnleblanc. The Genesis dev scene has really slowed down in my opinion. Fly your project to completion like an ACE!

by thefox on 2012-05-13 (#93744)

Baby steps... I finished a preliminary version of the 4 channel arrangement of the main tune. I also wrote a small tool to convert Tilificator project files to corresponding sprite definitions and CHR files (for HUD faces). It'll take some time before I'll be able to actually start using the converted data, because cleaning up the project is the priority for now.

by thefox on 2012-06-13 (#95460)

Note to self: time to get back on this bandwagon soon if I want to finish it by the end of the summer.

by tepples on 2012-06-13 (#95462)

If you need any help with this project, PM me here or catch me on #nesdev at EFnet.

by thefox on 2012-06-30 (#96248)

I've resumed working on this. I made a new git repo and I'm slowly moving stuff over from the old project, cleaning the modules and adapting them for MMC1. I'm currently using MMC1 because I need the WRAM, but hope to be able to switch to UxROM later, which should be a drop-in replacement because with MMC1 I'm using the 16K banking mode with CHR-RAM.

I've moved the map loading routine over and also wrote a new routine to load the nametable view. Previously I was using a routine from my multi-directional map scroller, which while works just fine, is unnecessarily generic/bloated for this project.

The remaining stuff (object handlers, sprite renderer etc) should be fairly straightforward to adapt to the new mapper.

by infiniteneslives on 2012-07-03 (#96452)

Nice to hear you're back at it, keep it up!

by thefox on 2012-07-04 (#96454)

infiniteneslives wrote:
Nice to hear you're back at it, keep it up!

Thanks, I will!

The project is advancing nicely. I've moved most of the stuff over now. I've also added some new stuff like better state handler (for different game states like menu, game itself, HUD display etc) and more manageable banking (using CA65's .bank pseudo-op).

For those who don't know what .bank is, it basically allows one to assign a bank number to each segment in the linker config, then retrieve said number based on a symbol. So stuff like this is possible:
Code:
lda #<.bank( someFunction )
jsr mapPRG
jsr someFunction

Definitely more manageable than specifying the bank numbers by hand every time.

Right now I have the level loading working again, with ability to scroll the levels horizontally and move up and down between screens using the controller.

One module that still desperately needs refactoring is objects.s: the object handlers. It has a bunch of references to some obsolete stuff which I've temporarily replaced with placeholders. But after that's all cleaned up I should be able to start working on some actual new stuff.

by thefox on 2012-07-07 (#96578)

Making progress once again. Let's see... *checks git log*.

Mostly I've been working on the "HUD", i.e. the textbox. It shows up properly, updates the nametable and the attributes, and uses sprite 0 hit to restore the level scroll afterwards. It can also display text already and as a quick mockup also displays Joe's face with some sprites. The only thing that remains to be implemented is restoring the level graphics (nametable + attributes) when the HUD closes (uploading stuff piece by piece when rendering is enabled is somewhat annoying...). I also need to implement some smaller stuff, like waiting for button press when text segment ends.

It's kind of ridiculous how it has taken me several days to implement something that probably took no more than 5 minutes on the original Flash game.

Oh yeah, I also did clean up most of the object handlers, so I have all the objects showing up in the levels once again.

The HUD faces will probably be what I'll be tackling next.

by thefox on 2012-07-08 (#96624)

thefox wrote:
The HUD faces will probably be what I'll be tackling next.

And so I did. I have Joe's and Command's face animations converted, and wrote some code to upload the CHR tiles etc when the speaker changes. Still to be done are the palette updates and restoring the level sprite CHR tiles when the HUD closes. Restoring the tiles is once again kind of a bitch because it needs to be done over multiple frames in the NMI because rendering is enabled. I guess I should write some kind of generic routine to transfer a chunk of memory to PPU while rendering is enabled.

I also need to convert the rest of the face animations, but that's fairly straightforward manual(ish) work that I'm probably going to postpone for now and use the existing animations as placeholders for other characters.

I think I'll start working on the player next. First thing to do would be to dynamically upload the sprite tiles as the player animation changes. Then from there I'll do the player movement: walking, and of course, "streeming".

by thefox on 2012-07-09 (#96646)

thefox wrote:
First thing to do would be to dynamically upload the sprite tiles as the player animation changes.

Did this today. I'm really glad to get this finally done because I've been putting it off for a long time. It has a nice and simple interface, I simply tell it the frame number that I want to display and it takes care of the rest. Currently it uploads 8 tiles per frame and splits the upload to multiple frames if needed. Naturally the animation will lag behind if an upload takes more than 1 frame, but all sprite frames use less than 16 tiles so hopefully it will not be too noticeable.

by tokumaru on 2012-07-09 (#96653)

thefox wrote:
Currently it uploads 8 tiles per frame and splits the upload to multiple frames if needed.

Are you double buffering the player's tiles?

by thefox on 2012-07-09 (#96655)

tokumaru wrote:
thefox wrote:
Currently it uploads 8 tiles per frame and splits the upload to multiple frames if needed.

Are you double buffering the player's tiles?

Yup. I have 64 tiles free in the sprite bank right now so there's plenty of space for that. I just hope I haven't forgotten about anything. I'm still kind of undecided whether I want to display score and deaths like in the original.

by Banshaku on 2012-07-09 (#96657)

Since this is becoming an interesting "log" of the state of the game, it would be great it during the progress some alpha build were available to see how it came from 0 to what it would be later.　I love those things, to see the progression with my own eyes.

Am I the only one to think that way?

by Denine on 2012-07-10 (#96664)

Banshaku wrote:
Am I the only one to think that way?

Nope.
So, thefox, any chances for some kind of "0.5"(half finished) version?

by thefox on 2012-07-10 (#96667)

Denine wrote:
Banshaku wrote:
Am I the only one to think that way?

Nope.
So, thefox, any chances for some kind of "0.5"(half finished) version?

Yes, I'll definitely consider it. I've been using version control for the entire duration of this project so I can actually go back and build any revision of the project at any time. So if need be, I could even show the intermediate builds after the project has been completed.

by thefox on 2012-07-12 (#96744)

Last couple of days I've been working on the player logic. It's done for the most part, he can run and shoot the streamer, I just need to fine-tune the physics etc a little bit more to make sure everything works exactly like it does in the original.

by thefox on 2012-07-15 (#96831)

I've made quite a bit of progress:

- Fine-tuned the player physics so they're pretty close to the Flash original now.
- HUD face palettes are now uploaded and restored properly.
- Worked on some sound effects.
- Added frame skipping when the game runs on NTSC (internally it always runs at 50 Hz like the original). The frame skipping doesn't look as bad as one might expect.
- System (NTSC/PAL/Dendy) is detected on bootup and everything is automatically adjusted.
- Thunder.
- Wipe in/out level transitions.
- Fixed all visual glitches from screen transitions (palette uploads outside vblank, disabling rendering midscreen, that kind of stuff).

It's starting to resemble a real game now. I may do a little video of it later.

by jayminer on 2012-07-15 (#96832)

I love following your progress!

A video would be awesome!

by thefox on 2012-08-02 (#97408)

I went vacationing in my hometown for a couple of weeks, so there's been little progress during that time. On 16th and 17th I fixed several small things and started working on the player death related stuff. It's time to get back in the flow.

3½ more weeks until school starts again. At this point it seems unlikely that I'll be able to complete project by that time, but I'll try my best.

Re: Streemerz NES port (WIP)
by thefox on 2012-08-09 (#97815)

Some progress:
- First revision of "music2". Unfortunately I don't have the MIDI/whatever for this so figuring out those snare patterns sucks.
- More sound effects: landing, death, thunder (some of them need more work still).
- Generic module for uploading data from CPU memory to PPU memory when rendering is enabled.
- Sprite tiles, nametable and attribute data are restored when HUD closes.

Re: Streemerz NES port (WIP)
by thefox on 2012-08-17 (#98295)

I've made 19 commits after the last post, so a lot of progress has been made:

- Checkpoints.
- Rewrote the collision checking routines (these were very old and kind of messy, some of the stuff like bounding box inclusion/exclusion wasn't well defined, now it's nice and clean).
- Keeps track of collected money.
- Sound effects: money, checkpoint.
- Fixed a bug in MUSE where channel volume didn't get properly applied on the triangle channel.
- Placeholder title screen state.
- Placeholder music: title screen, boss.
- Death collisions against all objects.
- Breakable blocks work perfectly now (they are restored when player dies etc.)
- A ton of other small miscellaneous changes/fixes.

In the original game Master Y's balls (as well as the grappling hook) use a rounded collision mask, next I'm probably going to look into how I could implement that in an efficient enough way. First I wasn't sure whether it's really worth it to implement it at all, but I've found that there are a couple of places in the levels where the collision mask does make a significant difference in difficulty (i.e. my version is harder right now). It looks like I can get a pretty close approximation by using 3 rectangles.

The biggest thing left on the TODO list (unless I've completely forgotten about something) is the boss fight (if you can call it that). I need to find an efficient way to store the route that Master Y takes together with all the other required state info (animation frame, streemer state). Fortunately that level is only about 1 minute long so it shouldn't be a problem. Hardest part will probably be actually constructing the data in the first place. If I had the source of the original, I could make it dump the state info for the entire run in a file, but no such luck.

Rounded collision detection
by tepples on 2012-08-17 (#98296)

Circle to circle collision detection is easy, or at least it was when I implemented it in Thwaite (missiles to explosions) and ZapPing (ball to paddle ends). First do the rectangle test, then look up (x2-x1)^2 and (y2-y1)^2 in a lookup table. You have a collision if (x2-x1)^2 + (y2-y1)^2 > (r1+r2)^2.

Circle to square, or in fact the more general case of two axis-aligned rounded rectangles, is quick too. Do you want me to draw a diagram explaining it?

Re: Rounded collision detection
by thefox on 2012-08-18 (#98316)

tepples wrote:
Circle to circle collision detection is easy, or at least it was when I implemented it in Thwaite (missiles to explosions) and ZapPing (ball to paddle ends). First do the rectangle test, then look up (x2-x1)^2 and (y2-y1)^2 in a lookup table. You have a collision if (x2-x1)^2 + (y2-y1)^2 > (r1+r2)^2.

Circle to square, or in fact the more general case of two axis-aligned rounded rectangles, is quick too. Do you want me to draw a diagram explaining it?

Thanks for the offer, but no need, I think I have it figured out.

Re: Streemerz NES port (WIP)
by thefox on 2012-08-20 (#98364)

More good progress. First of all, I implemented the circular collision mask for background tiles. I yet have to do that for obj-obj collisions, but that's not super important anyways. Then I started working on the boss level by exporting the invisible AI objects and using them to trigger stuff like moving left/right and shooting the streemer (the original games does this too). Unfortunately, my physics were off just enough to cause it to not work. So I rewrote the physics completely based on bytecode disassembly of the original game, so now they should be 100% faithful to the original (plus or minus some bugs I may have added ). After some time I also got the boss run level to work from beginning to end.

Of course I can't actually use the AI triggers in the final game because of problems that have already been discussed earlier in this thread (e.g. not having access to collision data for the full level at all times [technically it could be done, but it's just not worth the trouble]). So the next step is to log the boss state for each frame of the boss level, and then look for some way of compressing the data.

Re: Streemerz NES port (WIP)
by thefox on 2012-08-22 (#98437)

thefox wrote:
So the next step is to log the boss state for each frame of the boss level, and then look for some way of compressing the data.

And done (ended up using delta encoding + RLE, works well enough). I also started working on the 6502 code to play back said data. Bulk of that works as well, I just need to modify my player CHR uploader to be able to handle more than one upload simultaneously (one for the player, one for the boss, probably switching priority every frame).

Re: Streemerz NES port (WIP)
by thefox on 2012-08-24 (#98576)

thefox wrote:
And done (ended up using delta encoding + RLE, works well enough). I also started working on the 6502 code to play back said data. Bulk of that works as well, I just need to modify my player CHR uploader to be able to handle more than one upload simultaneously (one for the player, one for the boss, probably switching priority every frame).

The boss run thingy now works for the most part, phew! Running out of things to do... well, not really.

Re: Streemerz NES port (WIP)
by tepples on 2012-08-28 (#98730)

You asked in this post about tile compression. I used a pixel-level RLE codec for the Midwest Gaming Classic multicart that was similar to the codec tokumaru implemented. But after being disappointed in the decompression speed for a slightly more demanding application, I came up with something I called PB8 because it works on 8-byte blocks. I used it for an experimental update to my old Who's Cuter demo, and a couple months later, I refined it into the PB53 codec that I'm using for the menu in Action 53 and for the user interface graphics in my NES graphics editor.
Works on 8-byte blocks
Can decompress to a RAM buffer while rendering is turned on
Byte-level RLE for speed
Efficient even for tiles with only 2 colors, such as font glyphs
Can decompress multiple streams in parallel and repeat the corresponding tile from the previous stream, useful for NROMs that share a lot of tiles between banks such as Lawn Mower, LAN Master, and Slappin'
Maximum 12.5% expansion

Re: Streemerz NES port (WIP)
by thefox on 2012-08-28 (#98747)

tepples wrote:
You asked in this post about tile compression. I used a pixel-level RLE codec for the Midwest Gaming Classic multicart that was similar to the codec tokumaru implemented. But after being disappointed in the decompression speed for a slightly more demanding application, I came up with something I called PB8 because it works on 8-byte blocks. I used it for an experimental update to my old Who's Cuter demo, and a couple months later, I refined it into the PB53 codec that I'm using for the menu in Action 53 and for the user interface graphics in my NES graphics editor.
Works on 8-byte blocks
Can decompress to a RAM buffer while rendering is turned on
Byte-level RLE for speed
Efficient even for tiles with only 2 colors, such as font glyphs
Can decompress multiple streams in parallel and repeat the corresponding tile from the previous stream, useful for NROMs that share a lot of tiles between banks such as Lawn Mower, LAN Master, and Slappin'
Maximum 12.5% expansion

I took a look at it, seems pretty good! I'll definitely consider using it.

Re: Streemerz NES port (WIP)
by thefox on 2012-08-29 (#98777)

So, I didn't quite get it finished by the end of my summer vacation but I got much closer than I would've thought possible a couple of weeks ago. School started this Monday so it's going to slow things down a bit but I hope to get this finished in the next couple of months. If it has not been finished in 2012 somebody can come and kick me.

- Placeholder "win" state (when the end has been reached).
- STREEEEEMERZ mode (the gravity flipping thing) works 100%. All the other game modes are in place too (just needs specific stuff like the timers for the time trial levels).
- Added the rest of the HUD faces, though they need polishing still (went over the 8 sprites/scanline limit in some cases).
- Added RLE decompression routines (based on/copied from Shiru's unrle routine, so I can use NES Screen Tool).
- Added apLib decompression routines (based on/copied from mic's source, with a couple of small optimizations).
- Screens are compressed (got about 30% ratio out of apLib, I'm pretty happy with that). My goal is to fit the game in 128 KB.
- Menu selections can be made in the main menu.

All the big stuff has been done now, I think, but I still have plenty of small tasks left (60 or so items on my TODO list). By the way, if anybody is looking for a good Windows software for maintaining TODO lists, I recommend ToDoList.

Re: Streemerz NES port (WIP)
by tepples on 2012-08-30 (#98846)

Is this UNROM, BNROM, or some more complex mapper?

Re: Streemerz NES port (WIP)
by thefox on 2012-08-30 (#98855)

tepples wrote:
Is this UNROM, BNROM, or some more complex mapper?

MMC1 right now, but I'm going to convert it to UNROM later.

Re: Streemerz NES port (WIP)
by thefox on 2012-09-10 (#99335)

Time for another boring "text only" update.

- All sound effects are now done.
- All songs are mostly done, the drums need work on some of them (like I've said, it's a bitch to translate them based on audio alone).
- On-screen timer (for time attack modes). Still needs a little bit of work.
- Changed mapper to UxROM. I can easily switch between UxROM/MMC1 with compile-time settings.
- Fixed HUD faces to not use more than 8 sprites per scanline, they look perfect now.
- Smoke objects.
- Lots of bug fixes, big and small.
- Started working on the title screen.

It should be smooth sailing from now on. The main things left to do are the title screen and the statistics screen etc when the game ends. I think it's realistic to say that the game will be out in the next couple of months.

Re: Streemerz NES port (WIP)
by tokumaru on 2012-09-10 (#99336)

It's amazing how you managed to stick to this project and get this far. Your updates give us an idea of how much work goes into finishing a game, and how a lot of seemingly minute things play a big part in the overall scheme of things. Can't wait to see the finished project!

Re: Streemerz NES port (WIP)
by thefox on 2012-09-18 (#99794)

tokumaru wrote:
It's amazing how you managed to stick to this project and get this far. Your updates give us an idea of how much work goes into finishing a game, and how a lot of seemingly minute things play a big part in the overall scheme of things. Can't wait to see the finished project!

Thanks, I'm obviously very happy that I've been able to pull through this project, it hasn't always been easy. In fact, this project has shown me why it's no surprise that so few NES projects of this scale (or bigger) get finished. Making NES games is hard! With this project I of course had the advantage of having clear, precise goals (= the Flash game), so I always knew pretty well how the project was progressing. With projects built from scratch there tends to be a lot of uncertainty, but on the other hand they have the advantage of not having to worry about adapting stuff that may not fit the target system very well (in this specific case, the 320 px horizontal resolution, the way the levels were layered, etc).

Anyway, the game is almost completely done now. All I have left is ~~high score saving~~, credits and possibly adding some logos in there before the title screen. Then I'll take some time to add more polish, and we should be done here.

Re: Streemerz NES port (WIP)
by Nioreh on 2012-09-18 (#99795)

Totally awesome. I have been following this since the start, and enjoyed every update. Looking forward to release, even though I've played the flash game many times. I am sure there are more like me who follow it. I hope the lack of replies hasn't kept you from working on it.

I have been totally swamped at work this whole spring/summer, so I haven't had time to work on my own project. So it's always nice to check in on your progress. It keeps me motivated to finish my own game some day.

Re: Streemerz NES port (WIP)
by infiniteneslives on 2012-09-18 (#99824)

You've definitely been an inspiration for me as well. Seeing you make solid continual progress shows what's possible in a relatively short amount of time when you keep at it.

thefox wrote:
With this project I of course had the advantage of having clear, precise goals (= the Flash game)

I kinda figured this has been beneficial to you with this project. I had been considering holding off on doing much more until I fully defined my project, and your mention of it confirms my thoughts. I also like the todo app you suggested awhile back, unfortunately my lists just keep getting longer instead of things getting done, must be a bug in the app somewhere...

Re: Streemerz NES port (WIP)
by thefox on 2012-09-21 (#99969)

Thanks for all the comments.

I added high score saving, a placeholder logo before the title screen and shrunk the ROM from 256 KB (which I had been using for convenience) to 128 KB. I noticed the text scripts in their unpacked form take a lot of space, ~12 KB, but no point in trying to pack them at this point. The only thing left at this point is a credits scroller (and to actually figure out what to put in the credits...).

I also sent Arthur Lee (author of the Flash version) an email, hopefully I can get in contact with him to clear a couple of things up about credits, copyrights, logos and other stuff.

Re: Streemerz NES port (WIP)
by thefox on 2012-10-01 (#100634)

I've released a trailer at http://www.fauxgame.com

The game ROM itself will be released later this month.

Re: Streemerz NES port (WIP)
by Denine on 2012-10-01 (#100636)

Looks great!
You are really talented man, you know?
I'm looking forward it.

Re: Streemerz NES port (WIP)
by Bananmos on 2012-10-01 (#100637)

Ooh, I never should have watched that video... now I'll be refreshing this thread even more than usual in anticipation!

As for some tiny criticism, the 8 sprites/scanlines limit gets very obvious whenever you are at the same height as the score counters in that trailer. I hope OAM cycling is part of the final polishing? Or you'd probably even prefer to have the score disappear completely rather than the player/obstacles flickering too much...

Other than that, it looks/sounds just as cool as I hoped! Big congrats on sticking with this project!!

Re: Streemerz NES port (WIP)
by Shiru on 2012-10-01 (#100638)

Looks really good, a serious thing.

Re: Streemerz NES port (WIP)
by infiniteneslives on 2012-10-01 (#100639)

Are there any plans to publish this? I'd like to support the cause and buy a copy if possible. I'm guessing there is some grey area on rights to the material and such though? I just dislike the idea of how all the greedy/pirate reproshops are going to make a killing off your work... Might be a good selling point for the compo carts should they ever get published, but Tepples would have to move away from BNROM I guess.

Re: Streemerz NES port (WIP)
by rainwarrior on 2012-10-01 (#100646)

Looking good!

As far as rights to the material, I think thefox is relatively safe. The ideas taken from the original game are things that likely aren't copyrightable; does it go any farther than rope-shooting gameplay element, and the presence of clowns?

The title itself could be a problem if Active Enterprises was maintaining some sort of trademark on it, but given that they don't seem to have done anything with it in 20 years, that's probably not the case.

Re: Streemerz NES port (WIP)
by Jeroen on 2012-10-01 (#100652)

Thefox...all I can say is
http://www.youtube.com/watch?v=_XX-QV-bXRc

Really wanna play this and compare it to the flash version.

Re: Streemerz NES port (WIP)
by tepples on 2012-10-01 (#100654)

rainwarrior wrote:
The ideas taken from the original game are things that likely aren't copyrightable; does it go any farther than rope-shooting gameplay element

Which itself is taken from Konami's Roc'n Rope.

As for the mapper, would it be real hard to convert the code from UNROM (which has a fixed bank) to BNROM (which doesn't)? I can embed a BNROM in a BNROM.

Re: Streemerz NES port (WIP)
by infiniteneslives on 2012-10-01 (#100658)

tepples wrote:
I can embed a BNROM in a BNROM.

I understand the dynamics, did you mean to say BNROM inside a UNROM? Because that was more along the the lines of what i was thinking.

Re: Streemerz NES port (WIP)
by tokumaru on 2012-10-01 (#100659)

He can put a BNROM game inside a larger BNROM game, as in a multicart.

Giving up a fixed bank this late in development would be pretty hard, I guess. Unless he makes a 256KB BNROM game from a 128KB UNROM game where the last 16KB of every bank is the same.

Re: Streemerz NES port (WIP)
by rainwarrior on 2012-10-01 (#100660)

tepples wrote:
rainwarrior wrote:
The ideas taken from the original game are things that likely aren't copyrightable; does it go any farther than rope-shooting gameplay element

Which itself is taken from Konami's Roc'n Rope.

Or one year earlier the Atari 2600 had a game called Spider-Man that did something similar, but that's not really relevant anyway, because gameplay mechanics aren't normally subject to copyright.

Re: Streemerz NES port (WIP)
by tepples on 2012-10-01 (#100661)

What I meant is that I can include a game that uses BNROM in a multicart that uses BNROM by modifying the game's bus conflict avoidance table. So if you port Streemerz to BNROM, I can include it in Action 53.

Re: Streemerz NES port (WIP)
by infiniteneslives on 2012-10-01 (#100664)

Yeah sorry for derailing the discussion of what will undoubtedly be one of the best homebrew games we've seen into a mapper discussion...

All I was trying to say was that if there was a desire to combine action53 and streemerz (which I think would be epic) BNROM probably wouldn't work. On second thought That might not be case, I have some ideas if both parties are interested we can discuss them elsewhere. I don't want to do more damage to this thread.

Re: Streemerz NES port (WIP)
by thefox on 2012-10-01 (#100672)

Thanks for all the comments!

Bananmos wrote:
As for some tiny criticism, the 8 sprites/scanlines limit gets very obvious whenever you are at the same height as the score counters in that trailer. I hope OAM cycling is part of the final polishing? Or you'd probably even prefer to have the score disappear completely rather than the player/obstacles flickering too much...

Honestly, I don't find it much of a problem when playing the game because most of the action tends to be towards the center of the screen. So, we'll see how it goes after the ROM is released, I guess. I mostly expect to do a final beta testing round this coming week.

infiniteneslives wrote:
Are there any plans to publish this? I'd like to support the cause and buy a copy if possible. I'm guessing there is some grey area on rights to the material and such though? I just dislike the idea of how all the greedy/pirate reproshops are going to make a killing off your work... Might be a good selling point for the compo carts should they ever get published, but Tepples would have to move away from BNROM I guess.

Cart release is a possibility. I don't think there's any grey area, all of the content is original, and the author of the Flash version is OK with the idea of making carts. I am hopeful that the reproshops have enough dignity to not sell carts of this without permission.

tepples wrote:
As for the mapper, would it be real hard to convert the code from UNROM (which has a fixed bank) to BNROM (which doesn't)? I can embed a BNROM in a BNROM.

Hard to say, but I may look into it at some point in the future.

Of course if the multicart had a custom mapper with UNROM support, it probably would make it easier to find 53 games to fill it (Driar's 64KB UxROM conversion comes to mind as an another example).

Re: Streemerz NES port (WIP)
by Banshaku on 2012-10-02 (#100695)

I couldn't hear the sound of the video because I was at work but it looks great. I will be more than happy to try it out once it is out.

Congratulation so far!

thefox wrote:
I am hopeful that the reproshops have enough dignity to not sell carts of this without permission.

Well... I wouldn't put too much faith on that part.. ^_^;;

Re: Streemerz NES port (WIP)
by tepples on 2012-10-03 (#100710)

thefox wrote:
Of course if the multicart had a custom mapper with UNROM support, it probably would make it easier to find 53 games to fill it

I'm working with someone on such a mapper that can be configured at runtime to emulate pretty much any board that the discrete ReproPak supports. I'll start a new topic about it once it's further along in prototyping. But one drawback is that including a bunch of non-NROM games will require bigger flash chips.

Re: Streemerz NES port (WIP)
by B00daW on 2012-10-04 (#100743)

I like the company title "Faux" as if you were pronouncing it in English as "fox". Clever.

Re: Streemerz NES port (WIP)
by Dwedit on 2012-10-04 (#100744)

Quick question about the screen layout. Where is everything? It looks like stuff may be reaching the very outer edges of the screen. The ceiling at the top is also only 16 pixels tall.

Everything in dark blue is in the no-mans-land on my 1981 TV. Look at old NES games like Zelda 1, Super Mario Bros, and Zelda 2. Notice how they avoid putting anything important in the very top or bottom of the screen. In fact, in Zelda 1, the very bottom row is always a copy of the row right above it (for collision purposes).

Even PocketNES is going to crop away the top 16 and bottom 10 scanlines, before it scales the screen to 75% of its original height.

On a PC-based emulator or an LCD or Plasma TV, the cropping won't be a problem.

Re: Streemerz NES port (WIP)
by thefox on 2012-10-04 (#100748)

Dwedit wrote:
Quick question about the screen layout. Where is everything? It looks like stuff may be reaching the very outer edges of the screen. The ceiling at the top is also only 16 pixels tall.

Everything in dark blue is in the no-mans-land on my 1981 TV. Look at old NES games like Zelda 1, Super Mario Bros, and Zelda 2. Notice how they avoid putting anything important in the very top or bottom of the screen. In fact, in Zelda 1, the very bottom row is always a copy of the row right above it (for collision purposes).

Even PocketNES is going to crop away the top 16 and bottom 10 scanlines, before it scales the screen to 75% of its original height.

On a PC-based emulator or an LCD or Plasma TV, the cropping won't be a problem.

I've played through the game with 16 pixels cropped from top and bottom and 8 pixels from left and right, and the game is playable, albeit doesn't look perfect (it's hard to see where the openings on the ceiling are, for example). But even then, there's not much I can do to fix this due to the original resolution of the levels. I did think about adding vertical scrolling as an option, but didn't want to prematurely fix what could turn out to be a non-problem after all.

We'll see after the ROM release how big of a problem this really is.

Re: Streemerz NES port (WIP)
by tepples on 2012-10-04 (#100754)

I have a CRT TV and an LCD TV to test on. It may turn out to be the case that a few minor map changes are needed, similar to what was done for Lode Runner.

Re: Streemerz NES port (WIP)
by Sik on 2012-10-05 (#100770)

Dwedit wrote:
On a PC-based emulator or an LCD or Plasma TV, the cropping won't be a problem.

Beware that I know some LCD TVs do indeed crop the borders for some stupid reason, so no, even that isn't safe. Granted, the quality of said TVs is questionable for starters, but it happens.

Re: Streemerz NES port (WIP)
by thefox on 2012-10-05 (#100771)

Sik wrote:
Dwedit wrote:
On a PC-based emulator or an LCD or Plasma TV, the cropping won't be a problem.

Beware that I know some LCD TVs do indeed crop the borders for some stupid reason, so no, even that isn't safe. Granted, the quality of said TVs is questionable for starters, but it happens.

My Samsung LCD TV does crop the top 8 pixels or so from NTSC NES. Not sure about bottom.

Re: Streemerz NES port (WIP)
by tepples on 2012-10-05 (#100773)

My Vizio LCD TV crops the top and bottom 8 lines of the NES's 240p signal, but nothing on the left and right. I think the "stupid reason" is ultimately that a lot of video sources are noisy in the top and bottom 8 lines of each field. The picture might have artifacts of VHS or the like, a TV station might be using the top and bottom lines for some sort of data broadcast, or the program might even have boom mics that are just barely in the shot but out of the action safe area.

My Magnavox CRT TV crops similarly to PocketNES on the top and bottom: more lines are cropped on the top than on the bottom. I'm not sure whether this centering disparity is due to the 262-line fields (not 262.5 like the standard) or the 341-dot scanlines (not 341.25 like the standard). I might need to do some experiments with a Sega Genesis to distinguish these; it has 262-line fields but 342-dot lines if I recall correctly.

Re: Streemerz NES port (WIP)
by tokumaru on 2012-10-05 (#100774)

tepples wrote:
more lines are cropped on the top than on the bottom.

All CRTs I have ever used with my NES consoles crop more on the top too. Never payed attention to the other consoles though...

Re: Streemerz NES port (WIP)
by thefox on 2012-10-10 (#100912)

ROM has now been released at www.fauxgame.com, get it while it's fresh!

Re: Streemerz NES port (WIP)
by Nioreh on 2012-10-10 (#100913)

W00t! Gotta test on the powerpak when I get home!

Re: Streemerz NES port (WIP)
by jayminer on 2012-10-10 (#100914)

Yay!

Re: Streemerz NES port (WIP)
by tokumaru on 2012-10-10 (#100917)

Nice! Very impressive conversion, everything is as it should be! The only thing that bothers me a bit is the scrolling, I'm finding it a bit confusing. Since there's no way around this, other than redesigning all the screens, I'm sure I'll get used to it. I can't play much now since I'm working, but I'll definitely play more later.

Re: Streemerz NES port (WIP)
by djcouchycouch on 2012-10-10 (#100927)

Congratulations on your release!

Re: Streemerz NES port (WIP)
by Shiru on 2012-10-10 (#100928)

Great as expected. Still can't get through the second screen, though.

Re: Streemerz NES port (WIP)
by thefox on 2012-10-10 (#100932)

Shiru wrote:
Great as expected. Still can't get through the second screen, though.

You know — something to think about — after playing through this game countless of times while testing it, it's definitely easier to see why the developers of some of the old NES games felt the need to make the games so hard. IOW, after playing the game so much, your judgement of what exactly is "hard" does get skewed a lot.

After playing it so much, I might say it's not unfair to have a limit of 5 lives, with possibly some extra lives scattered throughout the levels, but I can remember that's not close to what I was thinking when I was playing through the Flash version for the first time!

Re: Streemerz NES port (WIP)
by Bananmos on 2012-10-10 (#100933)

Big big congrats to an eagerly awaited release!!

I've played through all modes already except "SUPERB JOE MODE", and it's just as awesome a conversion as I had hoped! And nice to see you got that title scrolling effect working so well!

I do however stand by my earlier statement that the sprite limit gets too visible at times... I'd still recommend you to always make the score/bonus counter sprites have the lowest priority so the sprite limit does not affect the gameplay.

Also, there's quite a few places where the original game had too many enemy sprites horizontally placed but where reducing them to fewer would have minimal effect on the gameplay... one example is the 9 parading clowns you encounter in "STREEEEEMERZ MODE"... having just 5 of them with empty gaps of space in between would require godspeed to squeeze between two of them.

I played it on my old CRT, and didn't notice the clipped lines at all... except for the fact that the top border of the text box frame got clipped, which looked a bit ugly but not crippling the gameplay anyway. So if it's easy to move it down by 8-16 pixels that would be appreciated, but it's no biggie

Re: Streemerz NES port (WIP)
by thefox on 2012-10-10 (#100935)

Bananmos wrote:
Big big congrats to an eagerly awaited release!!

I've played through all modes already except "SUPERB JOE MODE", and it's just as awesome a conversion as I had hoped! And nice to see you got that title scrolling effect working so well!

Thanks!

Quote:
I do however stand by my earlier statement that the sprite limit gets too visible at times... I'd still recommend you to always make the score/bonus counter sprites have the lowest priority so the sprite limit does not affect the gameplay.

I'll consider it.

Quote:
Also, there's quite a few places where the original game had too many enemy sprites horizontally placed but where reducing them to fewer would have minimal effect on the gameplay... one example is the 9 parading clowns you encounter in "STREEEEEMERZ MODE"... having just 5 of them with empty gaps of space in between would require godspeed to squeeze between two of them.

True. At some point I simply got in to the mindset that I want to change as little as possible, so there's the result. I'll consider changing this, too.

Quote:
I played it on my old CRT, and didn't notice the clipped lines at all... except for the fact that the top border of the text box frame got clipped, which looked a bit ugly but not crippling the gameplay anyway. So if it's easy to move it down by 8-16 pixels that would be appreciated, but it's no biggie

Yup, it's not exactly easy, because in that case I'd have to 1) set the scroll for the level 2) set the scroll for the textbox after a sprite 0 hit 3) use timed code to wait until the end of the text box (with different timing for NTSC/PAL/Dendy) 4) set the scroll for the level again. At the moment I can manage with just one split using sprite 0 hit.

It would look better though, I agree (even my HDTV clips the top 8 pixels), I just didn't want to add the extra complexity at the time. So, we'll see, maybe it'll happen eventually.

Re: Streemerz NES port
by Bananmos on 2012-10-10 (#100939)

So, I played through "SUPERB JOE MODE" as well... turned out to be quite an easy run, and I was pleasantly surprised that it was about racing some new areas in the last level as I just assumed up until the point I tried that it would be about trying to beat the full game in a mere 5 minutes of time...

No cheetahman ghost the second time around though, but I guess that feature would be pretty hard to pull off with the small amount of CPU RAM... though I noticed that the sprite table contains the gameplay sprites and the face sprites simultaneously, even though only one of those are visible at the same time. So if you feel for rewriting the communications code to have a big blank area in the sprite CHR, you could use that for storing interpolated delta coordinates. And since only 25% of the second nametable is used AFAICT, that gives another 0.75kB of RAM to streem to/from. Just a crazy idea, I totally understand if you feel it's not worth the effort

Quote:
Yup, it's not exactly easy, because in that case I'd have to 1) set the scroll for the level 2) set the scroll for the textbox after a sprite 0 hit 3) use timed code to wait until the end of the text box (with different timing for NTSC/PAL/Dendy) 4) set the scroll for the level again. At the moment I can manage with just one split using sprite 0 hit.

Ahh... I didn't realize you were using scrolling for this one - I just assumed you were doing the boxes like the pause box in Megaman1, rounding it's coordinates to the next tile boundary to center it on screen. If you feel like doing any timed code experiments though I have a Powerpak and both a NTSC/PAL console and would be happy to help you out with testing.

Re: Streemerz NES port
by rainwarrior on 2012-10-10 (#100941)

Good job! Fun game.

Re: Streemerz NES port
by thefox on 2012-10-10 (#100942)

Bananmos wrote:
No cheetahman ghost the second time around though, but I guess that feature would be pretty hard to pull off with the small amount of CPU RAM... though I noticed that the sprite table contains the gameplay sprites and the face sprites simultaneously, even though only one of those are visible at the same time. So if you feel for rewriting the communications code to have a big blank area in the sprite CHR, you could use that for storing interpolated delta coordinates. And since only 25% of the second nametable is used AFAICT, that gives another 0.75kB of RAM to streem to/from. Just a crazy idea, I totally understand if you feel it's not worth the effort

Yeah, it's probably not worth the effort, especially given that I've heard from several people that they think the ghost sprite in the Flash version is actually more confusing than useful (and I'd have to agree based on my own experiences).

Re: Streemerz NES port
by Banshaku on 2012-10-10 (#100944)

Congratulation on finishing the game!　

I played a little bit and the game play is good. That is quite an impressive homebrew! Congratulation again!

Edit:

I retract my comment regarding the music. The cause was the emulator I'm using on my psp doesn't play the music properly at all. After trying with nintendulator, the music was night & day. It's quite good and sound like the original, which I tried today to compare to figure out where was the problem I had.

Re: Streemerz NES port
by thefox on 2012-10-11 (#100953)

Banshaku wrote:
I retract my comment regarding the music. The cause was the emulator I'm using on my psp doesn't play the music properly at all. After trying with nintendulator, the music was night & day. It's quite good and sound like the original, which I tried today to compare to figure out where was the problem I had.

Ah, yes, many of the older emulators don't support blargg's sweep trick properly. I should maybe add a note about that on the download page, since it sounds just broken enough that people might think it's intentional.

Re: Streemerz NES port
by Banshaku on 2012-10-11 (#100954)

thefox wrote:
Ah, yes, many of the older emulators don't support blargg's sweep trick properly. I should maybe add a note about that on the download page, since it sounds just broken enough that people might think it's intentional.

Maybe a good idea. This is exactly what I was thinking first: the music was crap intentionally. It did fit the theme of the game! I was going to suggest that you improve the soundtrack to make it sounds better.. ^_^;;

Re: Streemerz NES port
by Dwedit on 2012-10-11 (#100956)

How many "illegal" instructions is this game using? So far I've seen CB, B3, and 8F. Now I need to emulate these.
Edit: Also need to fix the sound. Even though I should be emulating the sweep properly, I force the sound to play for one complete period before the frequency can change, so I'll need to find a way to change this.

Re: Streemerz NES port
by thefox on 2012-10-11 (#100957)

Dwedit wrote:
How many "illegal" instructions is this game using? So far I've seen CB, B3, and 8F. Now I need to emulate these.

Those should be all, I think. Only the sound engine uses them, so you shouldn't have to play it too long to find all the places where they're used.

Re: Streemerz NES port
by Denine on 2012-10-11 (#100959)

Good game. Never played original, though.
Man, I liked the theme of last stage Nice touch.
Too bad the whole game was sooo short!

Banshaku wrote:
I was going to suggest that you improve the soundtrack to make it sounds better.. ^_^;;

Maybe this game need a "NES Improvement mode"?

Re: Streemerz NES port
by slobu on 2012-10-11 (#100978)

Seems to work on the stock emulator for the Dingoo. Freakin' AWESOME!!!!!!!!!!!

I know I posted some pretty sappy words of encouragement earlier but I stand behind them. This gives me hope for my projects.

Re: Streemerz NES port
by tepples on 2012-10-11 (#101007)

This kicks @$$.

Re: Streemerz NES port
by Banshaku on 2012-10-11 (#101009)

I don't have much time to play games except for the train so I had to use some savestate to finish it unfortunately (and avoid repeating the difficult part). I really wanted to see the entire content so this was the only way.

I like it. Some spot were very infuriating but I guess it is normal for this genre. I'm not good for those type of games anymore, especially with the crappy controller on the psp. ^_^;;;

Congratulation again!

p.s. you should make a "broken music mode" that sound like the broken emulation thing. And I found one possible typo at the end, maybe it was intentional. I won't mention on the forum, just in case it's an intentional joke.

Re: Streemerz NES port
by Dwedit on 2012-10-11 (#101011)

I thought I was going to have to redo parts of my sound code, but nope, I was just getting a completely different kind of broken sound because I had bugs in my AXS #nn instruction. Frequency sweep tricks works fine.

Re: Streemerz NES port
by tokumaru on 2012-10-11 (#101014)

Do the "illegal" opcodes make such a significant difference for the sound engine or are they used just because?

Re: Streemerz NES port
by Dwedit on 2012-10-11 (#101016)

I just noticed that this game perfectly adjusts itself for PAL mode. Sound pitch is perfect, and gameplay and movement speed seems to be virtually the same. Edit: Dendy mode too!

Re: Streemerz NES port
by thefox on 2012-10-12 (#101037)

Banshaku wrote:
And I found one possible typo at the end, maybe it was intentional. I won't mention on the forum, just in case it's an intentional joke.

I left all the typos from the original alone, since I wasn't sure which ones were intentional and which ones were not (except for the very obvious intentional ones).

Dwedit wrote:
I thought I was going to have to redo parts of my sound code, but nope, I was just getting a completely different kind of broken sound because I had bugs in my AXS #nn instruction. Frequency sweep tricks works fine.

Hmm, I wonder if something like this was causing the sound bugging in other emulators (nnnesterJ at least) as well, I didn't actually check if it was the sweep trick. Oh well.

tokumaru wrote:
Do the "illegal" opcodes make such a significant difference for the sound engine or are they used just because?

Mostly just because. There was a time when I wanted to learn what the different illegal opcodes do, and the only way to do that was to apply them.

Re: Streemerz NES port
by Dwedit on 2012-10-12 (#101039)

Just a typo in my code that caused the AXS instruction to give very wrong results. The glitches were nothing at all like the other emulators. Sounded mostly like silence, clicks, noise, and low notes that followed the tempo of the song. Sometimes the game even rebooted.
Had nothing at all to do with the sweep trick, or problems that other emulators faced.
After I fixed the AXS bug, the music was perfect, and no more bugs.

Re: Streemerz NES port
by thefox on 2012-10-12 (#101040)

Dwedit wrote:
Just a typo in my code that caused the AXS instruction to give very wrong results. The glitches were nothing at all like the other emulators. Sounded mostly like silence, clicks, noise, and low notes that followed the tempo of the song. Sometimes the game even rebooted.
Had nothing at all to do with the sweep trick, or problems that other emulators faced.
After I fixed the AXS bug, the music was perfect, and no more bugs.

~~Is this in PocketNES, BTW, or some other emulator?~~

EDIT: Found out by myself (the answer is yes), the game works great in the latest version of PocketNES with VBA-M. Very nice!

Re: Streemerz NES port
by Dwedit on 2012-10-12 (#101041)

Yep, it's in PocketNES. I just released a new version that supports the game.

Re: Streemerz NES port
by Bananmos on 2012-10-14 (#101193)

Speaking of the music/sound effects I must add I'm quite impressed with how good and true to the original it sounds... while converting graphics is fairly straightforward, actually converting the Flash version to true NES sounds must have taken a lot of polishing, so congrats again on that

Re: Streemerz NES port
by thefox on 2012-10-24 (#101690)

Bananmos wrote:
Ahh... I didn't realize you were using scrolling for this one - I just assumed you were doing the boxes like the pause box in Megaman1, rounding it's coordinates to the next tile boundary to center it on screen.

You know, in hindsight I probably should have done this.

Maybe I'll change it for a new version so I can move the box down. It's not a trivial change though because all of the code assume that the textbox is at $2000 in the nametables, but at least I could get rid of the sprite 0 hit... I'd also have to fix all of the dialogue because there'd be less horizontal space.

I'm also considering scrolling the map down on NTSC ever so slightly (3 pixels seems to be the best) to make sure at least couple of pixels are visible on top and bottom when a display crops the top 16 pixels and bottom 10 pixels. If the croppings are more extreme than that, there's not much I can do.

Here's how the current version would handle 16-10 cropping:
Attachment:

crop-1.png [ 12.02 KiB | Viewed 5985 times ]

Here's how it would look after scrolling down 3 pixels: (Actually this mockup isn't 100% correct, the bottom 3 pixels of the map would show in place of the top 3 pixels in this case, unless the bottom tile row is cleared.)
Attachment:

crop-2.png [ 12.01 KiB | Viewed 5985 times ]

Re: Streemerz NES port
by qbradq on 2012-10-24 (#101703)

Man, this is really impressive TheFox! Way to go!

I'm only able to get to the part with the bouncing ball in the narrow shaft, but it's quite fun!

Re: Streemerz NES port
by strat on 2012-11-03 (#102282)

I tried getting all 16 dollar bags and could only get 14. Master Yyyyyyyy's baaaaallllllsss!

Re: Streemerz NES port
by Drag on 2012-11-14 (#102923)

So first of all, the music and sound was completely broken until I figured out I had to use a different emulator. I can't really fault you on that though, because I tend to use old emulators for casual gameplay (versus development).
The game looks impressive, in the sense that it looks like a game with high production values, which is usually uncommon for homebrew. However, it lacks some balance in the gameplay, which tarnishes the impressive look of the game.

This part right here is an absolute butt, and requires absolutely frame-perfect timing, or something very close. So, why is this so close to the beginning of the game? You don't want to frustrate new players (like me) right off of the bat, because it wears on the player's patience. Then again, maybe this is actually a simple section, and I just suck. If I suck though, why is the rest of the level no problem?

My suggestion for that part is to move the puzzle such that you eliminate the screen transition, since right now you "start" this section from the top of the previous screen, which feels unnecessary. That should help a little bit, but the section itself will still be difficult.

This is in the second stage, and I had to shut the game off at this point, because I was absolutely baffled as to how to get past this screen. With a lot of effort, I can get back down that staircase, but I don't know what to do from there, and if the solution actually where I'm standing in the screenshot, then it's far too difficult for me to sequence my shots to figure it out.

ON A RELATED NOTE, you may also want to consider toning down that death noise; it's way more frustrating than I feel it ought to be, especially since I hear it every 5 seconds, and I don't need extra frustration while I'm playing a game, and I imagine that there are other players who aren't me who will agree.

Also, consider revising "ROGER STREEMERZ COMMAND". It may not seem like a big deal, but it feels like unnecessary dialogue padding that doesn't add anything interesting, and just makes me need to hold the skip button longer. It also took me a second, but I'm assuming the Engrish-like writing is intentional.

So, you have a great concept and a solid engine, from what I've seen. However, the stage design is difficult to work with at times, and I can only take so much frustration before I'm turned off all together.

Do you have different BGMs after stage 2? If you don't, it'd be a shame, since you have a game that looks too polished and high-production-valuey to only have one song playing through the whole thing.

Re: Streemerz NES port
by thefox on 2012-11-14 (#102937)

Drag wrote:
So first of all, the music and sound was completely broken until I figured out I had to use a different emulator. I can't really fault you on that though, because I tend to use old emulators for casual gameplay (versus development).

Emulator support really was not a priority at all, I'm only happy if this project motivates emulator authors to fix their emulators (whether it's APU emulation, unofficial opcodes, or whatever).

People in general seem to be placing way too much trust on their old emulators to run things correctly (and that's not really too surprising, considering an emulator is just a "black box", so on the outside they really don't seem that different).

Quote:
The game looks impressive, in the sense that it looks like a game with high production values, which is usually uncommon for homebrew. However, it lacks some balance in the gameplay, which tarnishes the impressive look of the game.

This part right here is an absolute butt, and requires absolutely frame-perfect timing, or something very close. So, why is this so close to the beginning of the game? You don't want to frustrate new players (like me) right off of the bat, because it wears on the player's patience. Then again, maybe this is actually a simple section, and I just suck. If I suck though, why is the rest of the level no problem?

Well, first of all, the levels come directly from the Flash version. As for difficulty, it's very hard for me to objectively say anything about it. I don't think that screen is particularly hard, it definitely doesn't require frame-perfect timing. All I can say is that there's always a logical solution, one which doesn't require luck, so if something doesn't work, try doing something different. I do agree however that the difficulty doesn't increase linearly.

All things said I definitely can sympathize with you, I remember how frustrating the Flash version was, even on easy mode, when I first played. And now I can run through the whole game in time attack mode in 6 minutes (5 or so is probably possible with a perfect run).

Quote:
My suggestion for that part is to move the puzzle such that you eliminate the screen transition, since right now you "start" this section from the top of the previous screen, which feels unnecessary. That should help a little bit, but the section itself will still be difficult.

Thanks for the suggestion, but I don't like the idea of touching the original level designs at this point.

Quote:

This is in the second stage, and I had to shut the game off at this point, because I was absolutely baffled as to how to get past this screen. With a lot of effort, I can get back down that staircase, but I don't know what to do from there, and if the solution actually where I'm standing in the screenshot, then it's far too difficult for me to sequence my shots to figure it out.

The solution is right in front of you.

Quote:
Also, consider revising "ROGER STREEMERZ COMMAND". It may not seem like a big deal, but it feels like unnecessary dialogue padding that doesn't add anything interesting, and just makes me need to hold the skip button longer. It also took me a second, but I'm assuming the Engrish-like writing is intentional.

Dialogue also comes straight from the Flash version, and yeah, the Engrish is intentional. I did notice a couple of typos which probably weren't intentional, but I left them alone, because whatever.

Quote:
So, you have a great concept and a solid engine, from what I've seen. However, the stage design is difficult to work with at times, and I can only take so much frustration before I'm turned off all together.

Difficulty balancing sure is... difficult, because every player has a different opinion about it.

On a somewhat unrelated note, it would be an interesting experiment to gather playtesting data from a lot of players (could be as simple as a movie recorded in an emulator) and try to tweak the difficulty based on the results. But that'll have to wait for a future project.

Quote:
Do you have different BGMs after stage 2? If you don't, it'd be a shame, since you have a game that looks too polished and high-production-valuey to only have one song playing through the whole thing.

Yep there are a couple of more songs in there.

Re: Streemerz NES port
by Dwedit on 2012-11-14 (#102942)

In Streemerz, jumping is just weird. You *release* the button to jump, and you stay in forward motion, unless you had hit a wall on the way.
(just beat a normal playthrough of Time Trial mode, I think I had about 24 minutes, and 16/16 coins)

Re: Streemerz NES port
by rainwarrior on 2012-11-14 (#102953)

Drag, that room was one of two spots I had a lot of trouble with.

The key thing for getting past that plus-shaped thing is that if you shoot your cable out, and fall into a wall before it hits anything (i.e. the block on the right of the plus) you'll get a jump to happen. I found this really unintuitive, so that particular spot took me a while to figure out. You want to jump toward the plus-block and shoot your cable just before you would hit the block, and you'll get a jump when it catches.

Re: Streemerz NES port
by tepples on 2012-11-14 (#102958)

Try this: Stand on the top of the pyramid and face left. Grab the block on the right side of the plus. Grab it again to jump, and curve your jump to the top of the block. Then keep grabbing the ceiling to the left. There's a checkpoint immediately on the other side of the ceiling. There are harder set pieces to time before that, such as that bouncing ball in the column between the two platforms. About four rooms later, when the "lightning bolt" blocks start appearing, is where the music changes to a Jimmy Hart Version of the first area music from Bionic Commando.

Re: Streemerz NES port
by thefox on 2012-11-15 (#102982)

I've uploaded a multi-song NSF at http://www.fauxgame.com/streemerz.nsf

Doesn't seem to be working in some NSF players, probably due to the unofficial/illegal/undocumented/illogical/etc opcodes.

Re: Streemerz NES port
by unregistered on 2012-11-15 (#103019)

Hi thefox! This is an ~~excellent~~ amazing game! Thank you for bringing it to the NES! It is really funny... lots of laughing! My sister just beat the easy mode... I helped her get through a little bit after that fall where you follow the arrow to the left side of the screen. And she beat Y to the top! I couldn't quite make it last night. But I love the ending and we're going to have to beat it again! And maybe I'll try normal mode... I can't remember what you'all called it, sorry for that. : (

EXCELLENT JOB THEFOX!!

edit.

Re: Streemerz NES port
by unregistered on 2012-11-15 (#103023)

Hey, something happened me into Streemerzing... in STORY Mode and it's quite a bit harder. I got to the part where there was a guy who told me I should go back up that this challenge wasn't worth it... so I went back up and there's a ball bouncing in a narrow tower... think maybe that what qbradq was talking about... anyway I got up on the first ledge and failed about half a dozen times to get to the second higher ledge... and so I thought it would be fun to climb up the wall... and on my way up I entered an invisible door and it brought me to the level 2... and I was sad because I wanted to see what was up there... but I'm not sad any more. Hope this helps you!

Re: Streemerz NES port
by tepples on 2012-11-16 (#103035)

The invisible door that takes you to level 2 is less than a screen away from the actual entrance to level 2.

Re: Streemerz NES port
by unregistered on 2012-11-16 (#103043)

tepples wrote:
The invisible door that takes you to level 2 is less than a screen away from the actual entrance to level 2.

Thank you for telling me us this!

edit.

Re: Streemerz NES port
by Dwedit on 2012-11-16 (#103055)

Wow, that invisible door thing is surprising. It's even in the original flash version too!
Also, maybe you should change the color of Master Y's balls from $27 to $16, and possibly make them blink slightly more slowly. It looks really easy to do for the background balls, but do you have any space in the sprite palettes for this? Bright red death objects is something really bad to sacrifice.

Re: Streemerz NES port
by tepples on 2012-11-18 (#103165)

Someone managed to kill Dr. Tary in just the right spot between two negazones that the body never manages to settle.
Video (use Firefox, Chrome, or VLC to play)

Oh, and the reporter called a character "hitler stache chick".

Re: Streemerz NES port
by Dwedit on 2012-11-18 (#103169)

So I guess add a 10 second timer to force the body to be eliminated?

Re: Streemerz NES port
by thefox on 2012-11-18 (#103176)

tepples wrote:
Someone managed to kill Dr. Tary in just the right spot between two negazones that the body never manages to settle.
Video (use Firefox, Chrome, or VLC to play)

Yup, I'm aware of this bug, it's on the TODO list.

Re: Streemerz NES port
by Dwedit on 2012-11-19 (#103178)

I just triggered the glitch too, if anyone wants a FCEUX savestate...
Edit: I see that the Flash version simply does not let the body ricochet after getting hit.

Re: Streemerz NES port
by thefox on 2012-11-19 (#103179)

Dwedit wrote:
Edit: I see that the Flash version simply does not let the body ricochet after getting hit.

Ah, I must have missed that part, then it's going to be a very easy fix.

Re: Streemerz NES port
by zzo38 on 2012-11-19 (#103207)

I like this game. Maybe you should add time limit between checkpoints? Perhaps also, password of checkpoint, and if you collect money then if you die you should lose it.

Re: Streemerz NES port
by Feel on 2012-11-20 (#103223)

Excellent work, man!

I plan to make a repro of this game for my personal collection. Do you plan on doing some major future updates or is the game in its final state?

Also, i'll make a card sticker that i'm willing to share here, if people are interested.
Just let me know

Re: Streemerz NES port
by thefox on 2012-11-29 (#103685)

Feel wrote:
Excellent work, man!

I plan to make a repro of this game for my personal collection. Do you plan on doing some major future updates or is the game in its final state?

Also, i'll make a card sticker that i'm willing to share here, if people are interested.
Just let me know

Looks like I forgot to reply. Thanks, no, there probably will not be any major updates, but I plan to do release a new version in the next couple of months. That said there really haven't been any bugs found in v01 except being able to put Dr. Tary in an infinite bouncing loop when he's dead. That'll be fixed in the next version.

Re: Streemerz NES port
by thefox on 2013-02-01 (#107170)

I've released v02: http://www.fauxgame.com/

Not a whole lot of changes:
- Fixed infinite bouncing bug in Streeeeeemerz mode.
- Fine-tuned controller handling during screen transitions.
- Added French translation.

There were some issues with caching in the past, so try reloading the page if the link points to the old version.

Re: Streemerz NES port
by Dwedit on 2013-02-01 (#107195)

"La solution finale"

What?

Re: Streemerz NES port
by thefox on 2013-02-01 (#107196)

Dwedit wrote:
"La solution finale"

What?

And that's why there's a disclaimer about translation(s) in the README file.