News: 11 March 2016 - Forum Rules, Mobile Version
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - w7n

Pages: [1] 2 3 4
1
Are you going to tweak the original engine to support MMC5's extra channels, or insert an entirely new sound engine?
I'm going to design the engine so that it supports more effects in FamiTracker. Currently, the VRC7 engine already supports a few important effects like fine pitch. If I use the less time-consuming MMC5, I could insert more effect like arpeggios (even the 0CC scheme arps) so that its sound quality would still be good enough.

Glad to know this game isn't dead, it looks really good from what I've seen of it. Congrats on making a Super Mario Bros 1 hack to actually compete with Extra Mario Bros, one of those has been sorely lacking for a while now.

Still, where do you plan on posting updates about the project? Do you have a website or Facebook page or something?

Because I'd love to stay up to date with the game's development, but don't have any skills that'd help when it comes to actually working on a SMB 1 hack.
If you want to keep track of the progress (or offer help), please contact me in PM.

2
Notification for subscribers (also see top post):
This project is not dead. Unless this notice says otherwise or if 10 years have passed since this message was written (2017), this project is ongoing and will be hosted on RHDN (probably along with other sites) when released.
However, no updates will be posted on this page anymore. If you wish to join, contact me.
This is not due to any grudge towards the site (I have mostly none).

By the way, the final release might not use VRC7 after all, but MMC5 instead, due to the more flexible options and my own chiptune skills (VRC7 is actually my weakest spot)

3
News Submissions / Re: ROM Hacks: New Hacks Added to the Database
« on: July 20, 2017, 12:27:02 am »
Well, the FireM->BigM patch is actually my work (unless it's a coincidence that every byte of the two patch files match and even the naming is similar). It was originally made in 2011 and has a few unresolved minor issues.

4
An update of the IRL status so far:

I've currently in the first phase of setting up jobs about extracurriculum maths lessons, and so far I've been busier than before. Earlier, I expected to get back in April 2017 but I was horribly wrong. Probably by September 2017 I can continue work, because the summer vacation is the busiest time period for extracurriculum classes.
As of now, I'm in the starting phase of designing a level editor.

Will the finished product be functional on an emulator? It seems like a pretty complex rom hack.

Other than that, nice job so far. :laugh:
Do you mean functional on hardware?
Currently this ROM hack uses an arbitrary 'VRC7 4-screen' mapper for the 4-way scrolling, and this arbitrary setting is supported by VirtuaNES and FCEUX but not Nestopia and BizHawk.
However, since I might make this game into a general advanced SMB engine and probably deemed for mappers other than VRC7 as well, this problem may eventually be solved and I'll switch to a 2-screen mirroring. Although that means I have to rewrite the level loading routines again.
If one ever wants this to be functional on hardware he would need a VRC7 cart which is very expensive...

5
Currently the engine is only meant for this hack, but I might release a patch for the original SMB that implements the engine.

The level data format is still in the planning stage, but some of it has already been implemented in code. It has alpha-stage functionality in the project currently.
The following are adapted from my own notes. Feel free to fill in the missing blanks.

The level editor is being programmed in Delphi. I'm not really familiar with the IDE though, so progress on this level editor is rather slow. If you're familiar with Delphi then help is welcome.




C1 System architecture

1.1  I/O format of the editor
Editor-specific level data files can be in any format, but the editor should be able to output either hex files or compilable asm source.
The editor should output these files:
> Level data files
> Background files
> Table file for background of upr & lwr areas in H+V levels
Outputing to a compilable asm source is the recommended solution for level data, while outputing to a hex file is the recommended solution for backgrounds.
A line of an object in the asm source code looks like:
  HOR 0,3,8,14,QuestionFlower
The HOR is a pre-defined macro.




1.2  Hierarchy

First note that a 'metatile' is a 16x16px tile. The SMB system process almost everything about level loading in metatiles.


-- Area data --


               [decides w/table]         
(World number) ----------------- (Map bank) (Maximum size 8191 bytes)

Map bank file: Map**.65s (** denotes a number)

The structure of a map bank:


Code: [Select]
64 area data pointers (areas are labeled $00 to $3F) ------
 64 enemy data pointers -------------------------           |
                                                 |          |
  -----------------------------------------------+----------
 |                                               |
 V                                               |
 (Data of area $00)                              |
 Header part                                     |
 Objects part, with a specific termination byte  |
                                                 |
                                                 |
  -----------------------------------------------
 |
 V
 Enemy objects part and 'area entry' data part, with a specific termination byte





-- Background data --


Code: [Select]
         [Find ID of lower and upper area w/table]
                     /                  |            [BG is filled with a single metatile]
                    / Y                 |             /
                   /                    |            /  Y
(BG setting) -- [H+V level?]         (BG ID) -- [ID < 4?]
                   \  N                 |            \  N
                    \                   |             \
                 [Setting = ID] --------             [Look for the (ID-4)th background stored in the BG banks]



Background bank file: BGBank*.bin (* denotes a number, for example BGBank0.bin)

The structure of a BG bank is simple: One background is composed of 1 page, stores 256 metatile bytes. Thus a BG bank stores 32 backgrounds.

Code: [Select]
    0 1 2 3 4 ... F  (y)   +--------------> y
0   * * * * *     *        |
1   * * * * *     *        |
...                        |
F   * * * * *     *        V  x
(x)
The only thing needs attention is that xpos and ypos are not the same as aligned in a hex editor, instead they are swapped.



-- Metatile data --

There are a total of 256 metatiles available for use. Since the CHR banks are not fixed though, the metatile graphics are determined by several bytes in the level header: One is the area style byte (determines CHRBank4 and CHRBank5), another is the area BG byte.
To actually calculate the graphics isn't easy work perhaps, so the metatile GFX setting can be an editor-exclusive setting that is never exported.
Earlier, I've made a .BMP exporter to export metatile data.





1.3  How the map is preprocessed in the ROM hack

1.3.1  Basics

Firstly: a horizontal level takes up at most 16 pages, while a H+V level takes up at most 8 pages horizontally and 2 pages vertically.
For the map data, the lower part of an H+V level is stored separately from the upper part, and its ID is the AreaID of the upper part plus 1. And the lower part has no header.
For example, if you're loading area $0B which is an H+V level:

Area0B:
[Header]
[Objects]

Area0C: ;The corresponding lower part of area $0B
[Objects]

This doesn't apply to enemies: Enemies are all stored in Area0BEnemy, there is a flag to indicate whether the enemy object is in the upper or the lower area.

The y-length of a horizontal level is 13 metatiles, while for H+V levels it's 28 metatiles. Usually it's 28 = 16(upper) + 12(lower), the exception is the terrain.



1.3.2  The metatile map

We can say that there are 3 'layers' of the metatile map and they are written in the following order:

#1: Background.
Backgrounds are saved separately in the files, as explained above. The header includes a BG setting, and BG settings can be changed midway during the level.

For horizontal levels -- BG setting = BG ID. Only the top 13 lines of metatiles are actually used.
For vertical levels -- Use the H+V BG table to find out the BG ID for the upper and lower areas. The upper area takes all 16 lines, while the lower area only takes the top 12 lines.

The BG processing routine processes BG by column, and when it finishes column 15 it goes back to column 0.
Changing the BG setting midway does not reset the column of the BG renderer, instead it renders the changed BG from the next column.


Note that after BG rendition, metatile $00 will be treated as 'transparent' and doesn't overwrite the BG. Hidden blocks don't overwrite the BG ingame, but in the map editor showing them is better.


#2: Terrain.
Terrains are controlled by terrain bit objects, and the header also has two bytes for them.

For horizontal levels -- 13 lines
For vertical levels -- Upper = 15 lines, Lower = 13 lines

Terrain graphics have a Metroid-like approach: Although the existence of terrain blocks is only controlled by a bit on/bit off, the actual terrain block is determined by its surrounding blocks.
The terrain block metatiles are defined as such in the source code:

;123
;4 6
;789

TerNothing = $D0 ;This means a solitary terrain metatile
Ter2 = $D1
Ter4 = $D2
Ter6 = $D3
Ter8 = $D4
Ter24 = $D5
Ter24_1 = $D6
Ter26 = $D7
Ter26_3 = $D8
Ter28 = $D9
Ter46 = $DA
Ter48 = $DB
Ter48_7 = $DC
Ter68 = $DD
Ter68_9 = $DE
Ter246 = $DF
Ter246_1 = $E0
Ter246_3 = $E1
Ter246_13 = $E2
Ter248 = $E3
Ter248_1 = $E4
Ter248_7 = $E5
Ter248_17 = $E6
Ter268 = $E7
Ter268_3 = $E8
Ter268_7 = $E9
Ter268_37 = $EA
Ter468 = $EB
Ter468_7 = $EC
Ter468_9 = $ED
Ter468_79 = $EE
Ter2468 = $EF
Ter2468_1 = $F0
Ter2468_3 = $F1
Ter2468_7 = $F2
Ter2468_9 = $F3
Ter2468_13 = $F4
Ter2468_17 = $F5
Ter2468_19 = $F6
Ter2468_37 = $F7
Ter2468_39 = $F8
Ter2468_79 = $F9
Ter2468_137 = $FA
Ter2468_139 = $FB
Ter2468_179 = $FC
Ter2468_379 = $FD
Ter2468_1379 = $FE


#3: Area objects.
Area objects should always be sorted by their x positions, and the latter objects would overwrite metatiles created by former objects.
Objects on the same column can be manually sorted, but (if on the same column) objects in the lower area always come later than objects in the upper area and will overwrite their metatiles.

For horizontal levels -- 13 lines for normal objects, last 3 lines for settings
For vertical levels -- Upper = 16 lines for normal objects, Lower = 12 lines for normal objects and last 4 lines for settings

Note that if an object in the upper area is long enough, it will find itself occupying space in both upper and lower areas.



1.3.3  Enemies

Enemy data are separated from area objects, and they are much easier to document.
Enemy data also stores 'area entry'(where a pipe should lead to) data and other settings.

There are several sets of enemies, but only one set can be used at a time. Exactly which set to use is set(overwritten) by an enemy object.





1.4  Area object structure

Once again:
For horizontal levels -- 13 lines for normal objects, last 3 lines for settings
For vertical levels -- Upper = 16 lines for normal objects, Lower = 12 lines for normal objects and last 4 lines for settings

The termination byte for area data is #$FE, while the page skip byte for area data is #$FD. Otherwise, the first byte of an area object is always in this structure:

XXXX YYYY

X = X column, Y = Y column


Normal objects:

XXXX YYYY PAAB BBBB CCCC CCCC

B always denotes the object length. The actual object length is B+1.

A = Type of object.
A = 00: Special object
A = 01: Vertical block (starting from x,y and goes downward)
A = 10: Horizontal object (starting from x,y and goes rightward)
A = 11: Objects of infinite vertical length (starting from x,y and goes downward infinitely, then copied horizontally)

If A != 00, then B denotes the object length (B denotes the horizontal length if A = 11) and C is the metatile ID.

If A = 00, then C is the routine ID. For example C=0 means a vertical pipe.


Y==13:

XXXX YYYY PAAA AAAA

If X=15 this is the page skip object and there is no second byte. The object will be treated as if it carries a page flag by default.
Otherwise, the Ath routine will be called. Usually used to conditionally skip or load the next object, for example, if the player has Lens of Truth then skip / load the next object.


Y==14:

XXXX YYYY PAAA BBBB
XY = #$FE means end of data. Otherwise:
If A<>0, this is a setting object with B as a coefficient. List:
A=1: X autoscrolling. If B=0 then revert to normal scrolling.
A=2: Y autoscrolling. B=coefficient: 0=cancel, 8=stopped, 1=upwards fastest, 15=downwards fastest
A=3: Y scroll position autoscrolls to B*16.
(Others undefined for now)

If A=0: Setting object without coefficient. Current list:
0: Hard mode
1: Smart enemies
2: Enemies won't be removed if out of screen boundaries
3: Certain enemies run in normal code
4: Certain enemies' trajectory are set with preloaded code chunk 1
5: ...code chunk 2
6: Certain enemies fire a bullet aimed at the player every 4 seconds
7:
8:
9: Stop enemy frenzy
10: Checkpoint - start at bottom of upper area
11: Checkpoint - start at bottom of lower area
12: Scroll stop (x only, same as below)
13: Scroll stop (end of level)
14: Scroll stop (Megaman cutscene-ish)
15: Scroll stop (until all enemies onscreen defeated)


Y==15:

XXXX YYYY PAAB BBBB CCCC CCCC

A: Setting type.

IF A==00:
B: Palette type
C: BG type

IF A==01:
B and C: Terrain bits. If H+V level, then it stands for the terrain bits of the lower part.

IF A==10:
B: Lower 4 bits used, this means 'When player reaches a position that's the same as the object's x position and lower than B*16 px, trigger cutscene C'. If the high bit of B is 1 though, the Y judgement is ignored.

IF A==11: Setting object whose type depends on B.
B=0: Change BG (of the SMB's own mechanics, for example castle walls).
B=1: Preload chunk 1. C=routine number
B=2: Preload chunk 2.
B=3: Set the type of the next undefined powerup. The highest bit of C means upgraded status.
(Others undefined)


Y==12 of lower part of H+V level:

XXXX YYYY PAAA AAAA AAAA AAAA
A: Terrain bits.




Enemies:

Y<14:

XXXX YYYY PHTT BBBB R*EE EEEE

TT: Type. 00: Normal, 01: Appears on the left edge of screen, 10: Trigger, when the player touches its bounding box it disappears and triggers an event, for example 8 projectiles shoot towards the player. The third byte stands for trigger ID. 11: NPC with dialogue, this kind of enemy uses another format.
BBBB: Enemy type. Determines PRG and CHR bank used for the enemy. If B=0, then do not change PRG and CHR bank settings.
R: Random enemy.
E: Enemy ID. If R=1, E stands for random enemy setting.

IF T == 11 (NPC with dialogue):
XXXX YYYY PHTT EEEE CCCC CCCC
E: Enemy ID
C: Cutscene ID



Y==14: Pipe entry data.
XXXX YYYY PAAA AAAA EEEB BBBB xxxx xxxp yyyy WWWW
A: Entry area number
E: Entry type, 0=none 1=leftward 2=rightward 3=downward 4=upward 5=vine upward 6=vine downward 7= (undefined)
B: Entry page
x,y: X and Y coordinates. Actual X and Y coordinates are: xxxx xxx0 and yyyy 0000.
p: If p==1, then player appears at the lower half of the level
W: World number
Unlike the original SMB, this object doesn't work like 'when it's loaded then change pipe entry settings' but rather 'all entries right of this object use this setting'.


Y==15: If XXXX YYYY = #$FF then it's the end of data byte, else:
XXXX YYYY PABB BBBB
A=0: If B=0 then it's a blank object. Otherwise, B is the routine number. (Also may be used to conditionally skip objects) If the highest bit of B is 1, then it's not executed in real-time but rather in level data preloading.
A=1: Change BGM.



Level header:
> TTTT AAPP   T: Time setting (0=do not set), A: Area type, P: Initial Y position
> TTTT TTTT CSLT TTTT  C: Ceiling judgement (0: Ceiling hollow; 1: Ceiling has same attributes as the highest metatile of the same x position), S: Safe zone, L: Landform(terrain) GFX type, T: Terrain bits
> LSSS SSSS  L: L+R level, S: GFX settings type
> One byte for BGM
> One byte for starting BG
> VPPP PPPP  P: Palette, V: H+V level
> One byte for local map ID
> One byte which determines the level's position on the local map. YYYX XXXX
> TTBB BBBB   T: Time flowing speed setting, B: Player to background collision setting (used for moving background)
> Two bytes depending on the area type:
--If H+V level: The starting terrain bits of the lower area.
--If not H+V level: The two routine IDs for preloaded data.
> Finally a null-terminated string for the name of the level.

6
News Submissions / Re: ROM Hacks: Rohrleitung Gate - Action-puzzle SMB1 hack
« on: September 17, 2016, 11:28:07 am »
I dont think hunting for single hidden blocks or performing (tas) glitches and pixel-perfect jumps are puzzles.

Sure smb1 is limited, but it just doesn't work as an puzzle hack.
By stating you've faild to find what makes up the puzzles, it's highly likely that you have played just a first few tutorial scenes, and specifically not past the 1st world.
By the way, not only are glitches totally unrequired to complete, many of the glitches are also fixed in this hack.

This hack is not for everyone, as I've said in the news article. And I didn't design this hack to be intended for people not familiar with the smb engine.
In this community there seems to be a kind of opinion that people should think before making harder hacks. My opinion is, that still depends on the demographic.

7
Personal Projects / Re: SUPER STALIN - (Super Mario Bros. NES ROM Hack) WIP
« on: September 15, 2016, 12:10:20 am »
If only we knew someone who could make background bosses. Aside from that minor detail, this game is going along perfect.
Actually I do, a partly-moving scroll & collision detection mechanics is already made possible in my own ongoing hack. (Not that I'm going to contribute though, but you can have that part of ASM code if you want)

8
Gaming Discussion / Re: Metroid 2 remake released.
« on: September 04, 2016, 10:44:10 pm »
How much effort does it take to cut the game's ties with Metroid in legal aspects then?
Changing a few names is easy, while original graphics can easily be defined as the author's own works. And since ideas are not copyrightable, most if not all mechanics can be preserved. So it mostly comes down to the graphics of enemies and Samus and some other things. And if enemy graphics are original and don't clearly resemble original design, then they can be preserved too.
Anything I missed?

BTW if anyone wants to play a joke on this turn of events, he could draw an icon '2-10-1' (homophonic pun) on a sinking ship in a Metroid (or whatever) hack.

9
I've actually sent PMs to you earlier than this announcement. I don't think I want to play a specific role: If there is a bug, I'll report it, and I'll also post my thoughts on this hack.

10
Ai Senshi Nicol made good use of the FDS channels ... and Dead Zone makes uses of the FDS channels by using it for samples! Also that NSF sounds like it uses the N106 chip...
The vocal samples in Dead Zone come from the PCM channel (and actually uses PCM techniques instead of DPCM samples.)
The NSF I posted does use the Namco chip, but the lead vocals come from the FDS.

11
- Skate or Die 2 ("Skate or Die.  Skate skate skate skate or die. Die die die die die")
The Skate or Die vocals are PCM streaming instead of DPCM samples.

By the way, few games ever make use of the FDS well. If they had been more creative, then Vocaloid for FDS would have been released 30 years ago. (requires newest NSFPlay)

12
Gaming Discussion / Re: Metroid 2 remake released.
« on: August 22, 2016, 10:57:53 pm »
I heard that Nintendo don't have much of a presence in the country the Metroid 2 Remake developer lives in, so he's ignoring their DMCA takedown. He just released a update of his fangame too.
Nintendo has little presence in my country either (in fact it'd even still be long before piracy gets penalised in practice), so :-)
Or I'd just say: I have the game, and a bunch of Chinese sites are still hosting them with no chance of even being taken down.

13
A side note:
Since the game now preprocesses map data instead of reading it ingame, the amount of lag has been further reduced.
The original SMB game lags when there are 5 goombas on the screen(one of the laggiest enemy combinations) and new level data is being loaded, while here, (2A03 music + no IRQ) 5 goombas + 2 fireballs + player scrolling the screen produces no lag.

New powerup:
Ninja Mario(mostly a copy from that of Mario Adventure)
New ability:
Charge shot- Different suits have different charge shots, and exactly which projectile the player fires depends on the charging duration. Fiery Mario has only 1 charge shot: A fire wave which functions like Megaman's charge shot.

14
Just asking: How is the amount of yuri compared to the previous games? (Answer should be spoilered)

15
Update time (finally)
So, what do you expect from this update? How about...
>New level data structure which allows much more freedom in editing (Level editor is in progress though)
>Scrolling in 4 directions possible!!
>Minor update: An ability called Speed Booster, which... wait, you know what that is. I'm yet to add the shinespark ability though.

No demo image this time, sorry.
If everything goes well, hopefully I'll get to release a demo course by the end of September. forget it

16
OK, the normal quest is released and I probably won't be working on the hard quest afterwards (I'm shifting my focus towards Mario Gaiden). This release can basically be considered a complete product, but since it's technically incomplete, I'm not uploading it to the database.

See #1

17
News Submissions / Re: ROM Hacks: New Hacks Added to the Database
« on: June 27, 2016, 01:02:24 am »
That's a whole completely different ball game and you know it.  One is a global issue that cannot be solved with a few mouse clicks.  The other one is.
Frankly I really suggest you take a course about logic in school.
The logic behind this question is 'does not fighting oppression equal consenting to it', and obviously no.
Define the sets A = 'people who don't fight a certain type of oppression' and B = 'people who don't consent to said oppression', and A∩B≠∅, since A∩B='people who are not satisfied with said oppression but aren't fighting against it' -- and often they aren't fighting against it because they have a good reason, for example they have more to do in real life.
Moreover this statement here has a few conceptual confusion issues. If one isn't fighting against offensive stuff here and now, they could have been fighting against it elsewhere or in the past/future. And this indeed is the case with Kiyoshi Aman. This clearly doesn't equal the simple phrase 'not fighting'.

If you cannot understand what I said, then I sincerely suggest you to talk less and learn more, so that you won't be damaging the LGBT community's reputations, which is the last thing I wish to see.

18
ROM Hacking Discussion / Re: Are there any Namco-163 hacks out there?
« on: June 24, 2016, 06:35:53 am »
One question here:
Last time I generated an NSF using an altered FamiTracker engine. Though from the sound port writes log it seems as if all the writes are done in proper order, at certain points the sounds don't output correctly and instead output clicking noises instead (emulated in NSFPlay and is likely the same case on hardware).
Would you be kind enough to look into this problem? At the starting stage I choose VRC7 for my ROM hack but I'm considering changing the mapper to Namco 163 too, and I'm just worried about this problem. I can provide you the NSF if you want to.

19
Terribly sorry for a real long development gap. (Actually not all due to real-life issues, I had been participating in Famicompo Pico 2015 and won 1st in covers)
Anyway, this project isn't dead and I'm pretty much decided to continue working on it as long as I have spare time, but it really could progress slower due to real life issues(career and whatsoever).

A minor feature I've just programmed is the cheat feature: Enter cheat codes to get maximum invincibility time, maximum gold, rare equipment etc, but one use of the cheat code would set your continue count to 99 and name you a WUSS.

20
>>NukeOTron
Well, I can't answer your question right now, sorry...


New updates:

(Ignore the crap background)
Why is Mario killed? Answer: The middle part of the scroll is moving up but the ceiling is stationary, and Mario gets squished.

Also, what do you expect from a new powerup called Gunner Mario?
Gunner Mario fires rapidly in 10 directions, but only on the ground, and firing slows his speed down.

Minor updates:
>Spin jump is being made. It doesn't have the glitching of getting hurt when spin jumping onto 2 enemies (in SMW) Still, the graphics is incomplete. Spin jump can't break bricks below in this game.
>When you stomp an enemy, you can hold A to bounce higher.
>The accelerating & braking mechanic is faster, to make Mario easier to control. Also one important change: B no longer works as the running button. Instead, you simply run by holding the D-pad.
>Infinite continues... and extremely player-friendly continue mechanics. Continuing resets your score, but boosts your state to Fire Mario with Fire-bomb upgrade(i.e. 'Full Power Up'), and sends you back to the last checkpoint. Your continue count is recorded though.
>Some more DPCM samples which are played on the title screen.

Pages: [1] 2 3 4