80280715 visitors

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 - tomaitheous

Pages: [1] 2 3 4 5 6 ... 9
Gaming Discussion / Re: Homebrew related stuffs
« on: Today at 11:12:54 am »
There's a lot of talent and info here, and it's not specific to one console. That, and I think there's a cross over between demos/homebrew coding and hacking. It'd be nice to have something like that for homebrew/demo coders. Hackers could benefit from their pool of knowledge as well.

 Cool. I'll make a personal projects thread :)

But I've got at least a year's worth of stuff backed up before I can make that move.

 Depending on your hacking skill and experience, you can learn from what games you've taken apart - about their engines, and replicate that on the homebrew side. Or at least get some ideas/starting points. I've done that myself.

Gaming Discussion / Re: Homebrew related stuffs
« on: August 22, 2014, 06:15:56 pm »
Action RPG. Old Falcom style, mixed with a little bit of Zelda/Neutopia (screen section scrolling, you swing your sword).

A copy/paste for spritesmind:
See here: http://pcedev.wordpress.com/2014/08/21/game-2014/

Basically, I'm looking for pixels artists for sprites, BG tiles, map/area layout artists, portait/cinema artists, and chiptune musicians. So that's four different graphic artist positions (doesn't need to be filled all by the same person).

I'm also looking for someone to write the game story creation and design (and dialog as well). I have a game engine that's maturing, and I rather spend my time/resource as the coder and project overseer, not the designer/creator. I had an idea of setting, direction, and style (fantasy, action RPG, old school Falcom style) - but rest is up the writer/creator.

I've haven't worked on a game project like this, so the plan is to do a small single 'chapter' in an old school Falcom style action-rpg setting. Small characters (16x16-ish), high color, NPCs, dialog, some questing, a couple of minor bosses and one final boss, ...equipment, items, EXP, and money systems, etc. I'm not sure I need another coder, but if anyone is interested in contributing code/logic/AI/etc wise - I'd be open to the idea as well. It's all assembly - no libs (all custom code - 65x based). The target platform is PC-Engine/TG16 hucard (cart) 8megabit.

I have some place holder graphics and will be showing off some of the game engine soon. If you're interested or know someone that might be interested - post on the link (or my email), or PM here.

Gaming Discussion / Homebrew related stuffs
« on: August 22, 2014, 04:44:01 pm »
I was wondering.. what about a sub-forum homebrew?

Also, I have a PCE/TG16 homebrew that I'm working on and looking for people (artists, musicians, writers, etc). Is there a specific place in the forums that I should post such a thread? Or is here pretty much the safe bet?

ROM Hacking Discussion / Re: YouTube/Google Video thread
« on: April 13, 2014, 12:03:09 pm »
The subs are just for the video. I was gonna subtitle the cinemas in game, but the game is getting an English dub.

ROM Hacking Discussion / Re: YouTube/Google Video thread
« on: April 12, 2014, 05:39:16 pm »

 First draft fully inserted.

ROM Hacking Discussion / Re: How were original GB/GBC games developed?
« on: February 23, 2014, 09:43:39 pm »
One of the reasons why C and other high level languages weren't popular for consoles, is that the code generation was often larger than anything you did with assembly. That mattered quite a bit back then. Compilers were still rather unoptimized in the early to mid 90's (both code and speed). I would think the z80 would lend it self better to a C compiler than a 65x, but still, assembly isn't that hard. It's rather easy, actually. Macro's can help with consolidating code in the source file, so that it's easier to read - as well.

 That said, some Genesis games were coded in C, with assembly mixed in to speed it up. Ecco is one of them. But of course, 68k is very compiler friendly. Hell, coding in 68k asm is almost like a high level language compared to 65x asm - heh. 68k has got to be the easiest processor that I've ever coded for. It's almost a difficult task to write piss poor performance code for 68k.

ROM Hacking Discussion / Re: GB - when does Vblank-Interrupt occur
« on: February 23, 2014, 10:41:28 am »
The title says it all.
Please don't tell me something like this:
I just want to know about the normal Gameboy, I need to know after how many CPU-CYCLES a Vblank-interrupt might going to be fired up.


 If you're working on emulator related stuff (writing emulation code), this site is probably not the best place for that info.

 That said, just look at what you posted. The refresh rate of the screen is ~59.7 times a second. That's ~16.75ms per frame (the total time a frame takes, including vblank). Vblank is listed as last ~1.1ms. That pretty much tells you all that you need to know.

 The active display is 144 pixels. 144+vblank = 16.75ms. Vblank is ~1.1ms. Vblank is somewhere between 10 to 11 scanlines in length (which sounds about right, from memory). Vblank is going to happen every ~70,256 master clock cycles or 17,564 cpu cycles (the master clock is 4,194,304hz. Since all cpu cycles are exactly 1/4 the master clock, most emulators and docs list the 'cpu cycles' in the 1/4 format). The start of the display is 0, the end of the display is 144 (start of vblank). So, assuming vblank is 11 scanlines long - the vblank interrupt is fired ~16,317 cpu cycles after the start of every frame.

 If you want better precision than that, you'll need to look at some emulator source code or talk to an emulator author that knows the gameboy.

EDIT: The GB/C cribsheet says the vblank time is 10 scanlines. So there you go. I suggest you get that cribsheet (GBCribSheet000129.pdf)

Description Frequency/Time 1x Clocks 2x Clocks
Horizontal Scanline Time 108.7 μs 114 228
V-Blank Period (10 scanlines) 1087 μs 1140 2280
Mode 10 19.31 μs
Mode 11 41.37 μs to 70.69 μs
Mode 0 with 10 sprites per scanline 18.72 μs
Mode 0 with no sprites per scanline 48.64 μs
CPU Clock Speed 4.194/8.838 Mhz 1,048,576/sec 2,209,715/sec
Horizontal Sync Frequency 9198 Hz
Vertical Sync Frequency 59.73 Hz 17555/frame 36995/frame

Personal Projects / Re: Megaman 1 and 2 for PC-Engine upgrade/hack
« on: February 20, 2014, 09:21:17 pm »
Right now, we are a team of 2 people working on this. A bit more stuff needs to be finished on the ASM side (it's getting close though), and once that's done - we'll be entering into phase 2.

 The second part will be to actually remake/re-imagine the game. Not just a re-skinned game, but a new version of MM1. When I get to this point, I'm probably gonna need to bring some more people in, on the team. I have a pretty good vision of the direction that I want this game to go, but the devil is always in the details - and so I'll need help tweaking the design and balancing the gameplay, etc.

:oMy god I'd like this to happen so much !
Someone "clean" (i.e. who isn't from RHDN) should really report them.

 If anything, I rather Nintendo NOT know about it. It draws unwanted attention to the rom hacking community (IMO). We're not seen as much of a threat, and I personally don't like the idea that... that we might be re-assessed as a whole ;>_>

ROM Hacking Discussion / Re: Castlevania 3j Long Version with SRAM Support
« on: February 20, 2014, 04:29:33 pm »
Pointing out bullshit or past history is not trolling. I love how people automatically think any harsh criticism or negative comments are trolling in today's online society. Trolling would have been me posting something along the lines of "This hack is shit" then saying nothing else just to get a rise out of all of you. I actually have no problem with the hack and thought it actually looked kinda cool. This thread was linked to me by friends that do frequent this site as a sort of "BTW did you see this?" sort of thing. I replied to simply point out what I thought was bullshit and to show there was a past history of it. I did not have to go looking for this, it came to me.

 Well, for one - this isn't a console modding site. So I don't see how any of that is relevant. Two, it didn't come 'to' you. You came here. What he posted here, has no relevance to your modding scene. You basically came here to attack his character. Him personally, and in public fashion. So yes, while you didn't 'troll' us - you are trolling him. If this was another console mod themed site, then you might have a more valid point. But this isn't, and this thread isn't about whatever beef you two have (or you have with him). And that the fact you followed him here,... ~is~ stalkish. Because you have no other interest here other than to confront him personally, and make him look bad in front of others on an unrelated subject. Yeah, that's not stalking or trolling..

 I'm not defending anything Drakon has done, nor did I know what he's supposedly done (or care). But I am pointing out your behavior. There's no 'hot glueing' in rom hacking (well, maybe in the metaphysical sense), and he's not reselling someone else's work or stealing credit for it (that I'm aware of). So... if that's all you came here for, and you don't plan on to contribute to anything on this site/forum, then well.. don't let the door hit your ass on the way out.

ROM Hacking Discussion / Re: Castlevania 3j Long Version with SRAM Support
« on: February 20, 2014, 02:52:31 pm »
I dunno, comes off as a little stalkish/trollish...

ROM Hacking Discussion / Re: Castlevania 3j Long Version with SRAM Support
« on: February 20, 2014, 02:22:57 pm »
Skips: Did you come here/sign up, ~just~ for this thread???

Can't speak to Nintendoage but GBAtemp is none too fond of repros either. Be it in the ROM hack, unlicensed multigame or clone game world.

 Apparently Nintendoage is all about selling rom hacks as repros: http://www.nintendoage.com/forum/messageview.cfm?catid=5&threadid=93324

 My jaw about dropped to the floor, that no one even questioned whether this was a good idea or morality, etc. Hell, people were taking pre-orders before the thing was even finished, let alone much to even show off of the game (and there are better SMW hacks out there); rom/ips is still private . One guy mentioned that SMWC (or whatever that place it called), would be pissed. That was about it. I've known Guntz from Sega-16, so this really surprised me. Not just repro, but limited edition versions as well. A limited edition 'rom hack' on a cart, sealed? WTF is wrong people? If Nintendo every caught wind of that, I'm sure his ass is going to court. Morality aside, the risk isn't worth the reward (and he's advertizing this on other forums now, not just Nintendoage).

Personal Projects / Re: Megaman 1 and 2 for PC-Engine upgrade/hack
« on: February 20, 2014, 09:35:20 am »
Thanatos-Zero: Thanks for the info. I'll try to get in contact with him.


Did a new power meter system. Gone is the old two columns of sprites, replaced with a single 16pixel wide column. For regular weapon, the bar represent all health, but when any other weapon selected - then the bar is split (the transparency mesh, behind the bar, helps you see it better). It's all direct pixel work, with some acceleration (tables). It takes one full scanline to draw it and transfer it to vram (455 cpu cycles), so fairly lite on the cpu. Cuts down on the number of sprites in the table, as well as the horizontal sprite bandwidth. There's going to be an icon at the bottom of the bar, to show which weapon is selected. The colors and graphics for the bar aren't final; that's just a WIP place holder.

 I'm working on upgrading the tilemap routine as well. Originally, I was going to do straight 8x8 pixel maps for the rooms with no 32x32 metablocks, but that bumps up the space from 64bytes to 2048bytes per room/segment. Not a big deal for cart (hucard version), but space can get pretty limited for 256k of the CDROM (I'll probably end up doing level loading anyway).

 I'm thinking I might just extend the 32x32 meta tile map format to 16bit entries. I figured, I can do a 16k decode table that will give me sixteen 8x8 tiles ~all~ with unique subpalette tags. That's enough for about ~630 32x32 decode blocks. Each 8x8 tile in the decode block would be 9bit (512 tiles to access) and subpalette will be 4bit (16 subpalettes to access) - all bitpacked to cram it into the 16k block. Each level will have its own 16k decode table. And the room map will only increase in size from 64bytes to 128byts. The downside, is creating a converter app for this :/

ROM Hacking Discussion / Re: Castlevania 3j Long Version with SRAM Support
« on: February 19, 2014, 07:00:22 pm »
The fact remains that he'd be making money off of copyrighted material.  :police: It would be different if he was making an NES homebrew totally from scratch using characters of his own design. I couldn't care less if he releases his romhack for free, or at all.

 Not if he's selling the patch itself. If the patch contains nothing but his original work, regardless of how it's applied to the application, it's still his work. He can't sell the rom, but he could sell the patch. Or go about it a different way; release it to the public once enough people have 'donated' or the amount donated meets his goal/whatever. Not so much different when people hold beta carts and such - private, until enough people 'purchase' his decision to make it public (dump the game).

 I don't personally do this, but I also don't attempt to dictate what other people do with their time/work. Just because I, and other people, give away their hard work - doesn't mean everyone else should have to as well. To each their own.

ROM Hacking Discussion / Re: Castlevania 3j Long Version with SRAM Support
« on: February 19, 2014, 01:32:19 pm »
What would be really cool, if you hacked Rondo on PC-Engine to have all the levels and boss from CV3. Surprised no one has attempted hacking that game. It's not like 6280 is much different than 6502, and a lot of romhackers have cut their teeth on 65x.

ROM Hacking Discussion / Re: NES ROM Compression Help
« on: February 13, 2014, 04:51:53 pm »
So I have a Castlevania hack I been working on and I have managed to edit some of the graphics using Tile layer Pro. However I've reached a point where there is stuff I'd like to edit but it is compressed and I can't really tell what m looking at. Is there a program that can decompress the sprites or make it a tab bit more easy when viewing the sprites so I can edit/replace them. Any help would be great.

 Maybe check to see if there's an expansion hack, as well as a chr-rom hack of the game. Chr-rom stuff is uncompressed. Even if you did decompress the graphics for chr-ram, there's no guarantee that it will compress and fit back into the original space. Usually best to ASM hack the game, expand the rom, and have it point to uncompressed tiles instead. Of course, this isn't easy (and requires of processor specific assembly), but like I said - you might get lucky and find that someone already did this, and build on top of that instead of the original rom.

Personal Projects / Re: Megaman 1 and 2 for PC-Engine upgrade/hack
« on: February 12, 2014, 02:34:58 pm »
So I was able to simulate the hack with mednafen and medgui. Some comments so far :
1) The music doesn't stop when it's supposed to when you die
For that short period, for the megaman dieing sound? I didn't bother muting the CD track, 'cause I didn't think it was such a big deal. But I'll put that on the list. That, and all system bios calls (for handling CD audio) pause the emulation. That would be very annoying. I'll have to see how I can replicate that specific bios function, inside the game code.

2) Similarly, the music doesn't stop when it's supposed to when a boss dies
Same as above. I'll put it on the list of things to do.

3) This is purely a matter of opinion, but I think it'd be nice if some of the short songs, such as "boss selected", "game over" and "victory" were still chiptune.

 I can add that function to the options menu; pick which is played for song # - cdda or psg. Though one could just easily make PSG tracks for that in wave format.

4) Is this based on the PAL version ? There is a low pitched noise after the shooting sound effect.
No. It's NTSC. Sweep emulation isn't.. emulated yet. From what I've read, even though MM doesn't setup those regs, it doesn't initialize them either. I suspect it's from that, because from everything else I've checked - all period values fall exactly inline with what they're supposed to be.

 I'll be converting the sound FX into a VGM style format (time based period/reg updates) pretty soon, and get rid of ~all~ APU emulation (replaced with custom PCE sound driver). That'll be the first thing I'll clip (that trailing sound from the weapon fire). 
5) The "stage select" music was SOOOO much better in the old version. Why change it ? This one is VERY lame, and is wrong
6) Even though the Wily stage music got replaced, Wily stage 2 music is wrong (it's from Mega Man 3), and anyways both sounds way too much heavy metal to me. So my comments about Teck's versions still apply.

I personally think MM music as rock/metal sounds good to me. It fits for me, but there aren't enough cover tracks to fit. The game is distributed into two separate parts; CUE/ISO and Music pack. I was never happy with all the tracks, rock/metal or not, so it's up to the individual to replace the tracks with whatever they want. They're wave files; easy enough to do.

7) Is there a way to make the music loop more elegantly than fading out, stop, and fade in again ?
Edit the wave files. All the fading and space between looping is in the wave file itself. If you use absolute start/end of the wave file, you'll get tight looping.

8 ) I really hate hate Ice man's stage. Oops this is not related to this hack, sorry ^^ This'd be the easiest game of the series if this weren't for Ice Man's stage.

 The flying platform part? Just get the beam/platform item from Elecman's stage; it makes Iceman's stage a breeze. The only hard parts in the game, IMO, are the Blob boss and the MM clone boss (relative to the rest of the game).

 MM update: Cutman's enemy sprites are now all converted over - https://www.youtube.com/watch?v=5i48xMQX7NI
Still tweaking the MM animation (running frames need more tweaking).

ROM Hacking Discussion / Re: Asm hacking
« on: February 06, 2014, 10:32:54 pm »
I mostly work with the GB(C) using bgb and wla-dx. wla-dx allows me to put my code on top of a base ROM, so it takes care of the code injection for me.

I couldn't imagine doing a large-scale ASM hacking project without an assembler. Memorizing the opcodes would be tedious, but that's not the main problem... the assembler is simply much more flexible. I can move code around, define labels, insert comments, easily. This is all stuff I consider necessary for big assembly hacks.

 I feel the same way. The flexibility of an assembler is a must. Changing even a one or two instructions, or such, can change source code and code alignment. I can't imaging doing that by hand, unless the replacement code was nothing more than a few bytes.

I hack completely via a hex editor. I like to be able to view everything with the Code Data Logger within FCEUX.

Everyone has they're own method of writing 6502. I happened to learn mostly from kuja killer, and that was how he wrote/modified 6502 asm.

I can look at hex values and know just about all of the opcodes for them from memory.

I've gotten so much flack from people saying I don't know how to do asm if I do it via a hex editor. It doesn't matter how you write it or what method you use, as long as it works.

I'm sure if I learned from someone else, and they actualy 'wrote' it out, then probably today that would be the way I write asm.

 Well, that's not ASM or Assembly. That's "machine language". I mean, if you're writing code directly in a hex editor. Assembly has a syntax, even if it's nothing more than bare bones mnemonics (although almost all assemblers have a higher level functionality to them as well). There's nothing wrong with that though, if you're completely comfortable with that approach.

 Being an assembly programmer and being an assembly hacker, aren't mutually exclusive. Being one, doesn't equate to being the other. Well, IMO. Don't get me wrong, I'm not here to criticize anybody. Hackers (that hack code) are a strange and special lot. The patience and time it takes to unravel someone else's code and understand it; not every programmer is cut out for that kind of stuff. And so I was curious, how many people moved onto using an assembler for their replacement code in hacks. Of course, I'm assuming most here don't have a background in assembly programming.   

 Anyway, for asm hacking - I always include the base rom or binary (extracted from CD) into the assembler and simply assemble new code directly over it. Same with data. Here's just one small file, of many, for my Megaman hack:

ROM Hacking Discussion / Asm hacking
« on: February 05, 2014, 04:43:40 pm »
Curious, how do you guys handle your ASM hacking projects?

 Do you use a hex editor to do all your asm hacking, or do you use an assembler? If you use an assembler, do you assembly directly into the rom or do copy the assembled code into the rom?

Pages: [1] 2 3 4 5 6 ... 9