Images

[Off-Topic / Re: Random Pictures Thread]

^Enthusiasm. When you have it, but you're not sure what to do with it.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

14 was the return total (pla, tam, and rti)
The int call is 8 cycles, the RTI is 7 cycles. That's the minimum you can possibly have on the PCE.

 Anyway, look over this:
/HuPCMDriver/TIRQ_playnice.png

I changed a few things around. "in_progress" can be used as both temporary bypass (sample currently being fetch/played), or to complete stop sample playback (because it can't undo itself if the condition is set outside the IRQ routine).
 
 I also decided to wrap the timer decrement inside a protect area (interrupts disabled). Just in case some wild edge case scenario showed its ugly head. You don't want a second call (overlapping TIRQ) to decement the counter while the previous call was in the middle of updating (resetting it back). The question is, would that be a bad thing if it did happen?

 So for stalling H-int, the longest is 44 cycles, mid is 30 cycles, and minimum is 22 cycles. The code is a little difficult to follow at first, because I'm trying to optimize for few case cycles per delay. You might notice that if a sample is going to be played, interrupts are enabled during that process, but disabled for the counter. If a sample isn't played, the branch that skips it - leaves interrupts disabled until the counter decrement can finish its process.

 Actually, worse case scenario of H-int delay would be 45 cycles; no sample to play, decrement counter but no psg player call, exit routine.


 So, you want overhead? Just the overhead of the decrement counter and no sample playing or player call? 45 cycles per call (a call being TIMER set to max speed). If you re-sync TIMER on internal vsync interrupt, you get a nice integer of 116 calls per frame (and no drift of the psg player relative to the frame - async.. eww). 116*45 = 5220 cycles or 4.38% cpu resource overhead.

Note: I think you stated something like 433 cpu cycles per scanline. I'm not sure if you were talking absolute or relative to overhead: VDC scanline is 455 cpu cycles long (the frame rate of 262 mode is something like ~60.1hz).

Is it slower on 6280 vs. 6502?  6502.org lists it as 6.

Some things are +1 cycle longer on the PCE (but unlike the 65x, there are no page boundary penalties.)


EDIT
Opps. I forgot to update ".EOF". It should read like this:
pla
tam #$04
jmp .TIMER_sampledisable

 Where .TIMER_sampledisable is a label point right after stz <in_progress.

[Localizations, Games, Apps, Docs / Re: MML: What are people's actual complaints with the damn thing]

GBz80..wooh.. no good. I haven't written GBz80 in a long time, and I have recently looked back on it - yeah, no. To a lesser extent, real z80 too. When I code on the z80, and GBz80, I feel restricted by the force use of smaller register-register operations (and 90% of them still have to be done through one reg: "A" reg). I miss the direct memory access of the 65x, and the labels you get to use (keeping everything in regs instead of direct memory with labels, made the code harder to read IMO).

 Old Man: From what I remember my tests showing me, when the VDC transitions from "hsync" (or more accurately; the period/window where the VDC waits for VCE to trigger it to move onto "back porch" area) to the actual blanking line (blanking level), is when the VDC will generate an interrupt for the cpu. You can test this, because while the VDC is setup for a "waiting window" for the VCE to trigger it, the VCE trigger itself ALWAYS moves the VDC back to "front porch" area - no matter where it is in the scanline (the VDC's front porch, which when unaligned is not always the VCE's front porch). This is how you can get the VDC to show two individual lines of graphic data on the same VCE NTSC line. Does this make sense?

Maybe this pic will help:


 The VDC enters a mode where it waits for the VCE to trigger the start of the next scanline. In the pic, that would be the "sync tip" area. And where you see the line going back up to 0 IRE, that would be the position in VDC "world" where the H-interrupt is generated. That "sync tip" is what the VDC manuals refer to as "horizontal sync pulse width". But since the VDC is in subordinate mode (requiring external interrupts to provide the image frame work), this is just a wait delay. It's set in segments of 8 "VDC" pixels wide, but if the VCE trigger in the middle it, then the VCD immedialely transitions into the next phase. So it's not going to actually be 8 pixels long. You could set it to be 24 pixels long; it won't matter. The VDC also immediately reads the X and Y position buffers and works out the logic for how to process the current line (sprites positions, BG positions, etc). I doubt you'd be able to get a fast enough routine to update these regs in time anyway, so that's why changes to regs happen on the following line. That way, if the H-int routine gets delayed then it should be affected. But that all depends on how close the reg updates happen relative to the start of the H-int routine. 

tl;dr: H-int happens at the very start of the back porch, when sync level goes to 0 IRE (right before the color burst in the pic). And if I remember correctly, the VCE adds a 8 pixel delay from what the VDC is displaying to what you actually see on screen. But that probably shouldn't effect what you're doing unless you're trying to change VCE regs per scanline.

 It's a little bit confusing in understanding the VDC in relation to the VCE. The VDC on the PCE doesn't generate hsync pulse or the color burst area, because it's in subordinate mode, but the regs will always be setup as if you're defining a real line. So I used the term "back porch" to keep things relative in talking about where in the line stuff happens on the VDC.



 So, I didn't really follow along of what you're trying to solve. What timing issue are you trying to work out?

[Off-Topic / Re: Random Pictures Thread]

Camo ninjas apparently wear eye liner ?

[Off-Topic / Re: Random Pictures Thread]

[Off-Topic / Re: Donald Trump Thread aka End of Days]

NW a is republican hard-linear.


 I dunno. I think political discussions are much better with other independents - regardless of which way they tend to lean (left, right, whatever). The party-line towers drank too much of the kool-aid too have a realistic political conversation with ;)

.

.

.

.


"Must...vote...party...line...must...vote...party...line...must.."

[Off-Topic / Re: Game Sack]

My dinner themed well with the episode.

What.. no sushi, only rolls!?

[PCE/TG-16|CD/SGX Discussion / Re: Sequels on PCE "without" Part I]

XZR -> XZR2 (Exile) -> XZR3 (Astyanax) -> XZR (VCR)

For years I wondered wtf XZR stood for until I actually looked at the kana title that comes with it in boxarts.
XZR -> Ex-Zee-Ar ≈> EkuZiAru ≈> エグザイル -> Eguzairu -> Exile



What does this have to do with this thread? Absolutely nothing.
Hey, we only got the third A-Train on the PCE.

Thanks for this! I always wondered about that as well.

[PCE/TG-16|CD/SGX Discussion / Re: Review: Dragon Egg - A Good but Rushed Platformer]

I love that you put in the clouds from the game xD

SignOfZeta: Completely agree on the transparencies thing.

[PCE/TG-16|CD/SGX Discussion / Re: What Turbo game are you currently playing?]

All I can say is...

 

Is that editable?

[Localizations, Games, Apps, Docs / Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.]

This belongs here:

ccovell: How did I not know about this demo!?

I've asked myself that question, too.  :-|  Maybe people were preoccupied at the time.

Anyway, depending on the odd/even phase of the VCE at the time that you make it static, dithered patterns consistently give either a usable red (verging a tiny amount towards orange) channel over 15 shades, or a cyan (harder to wrangle because it is 2 RGB channels combined.)  So:


Another test demo: https://chrismcovell.com/data/OldIsBeaut-Test.zip

I didn't use any special tools; removing the R channel from 24-bit pictures is good enough, and the R can be remapped separately to greyscale, or some ramped red/grey; the remaining G&B can be remapped down to PCE BG palettes, since there are now 64 colours possible per tile that have to be reduced.

[PCE/TG-16|CD/SGX Discussion / Re: Motteke Tamago Title Englishification]

Here's the latest build running in mednafen:

Wait.. how did you get that title screen in there?

[PCE/TG-16|CD/SGX Discussion / Re: New PCE chiptunes thread]

I got my cover to work within 60hz by switching between 100 and 90 bpm with effects, so it should be at the correct tempo on a real system. I also changed the noise volume from 1D to 1A since Deflemask's noise emulation seems to make it too quiet (it's much louder in the emulators I've tried). I don't have an Everdrive or a PC Engine on hand so I had to use Mednafen as a test bench.

Download: AcidJazz5-HES.zip

Awesome! Yes, the whole noise level thing from Deflemask's output has stopped me from doing music disks for roms.

 Do you have any graphics or animation you'd like to throw together for this hes to be a single music disk rom?

BTW: the HES file is using the TIMER interrupt to set the tempo. I raised it to 72hz (through the debugger).. sounds pretty great at high tempo too (nice high energy sound).

[PCE/TG-16|CD/SGX Discussion / Re: Hucard / SuperCD are NOT the same system...]

Nothing inside the SFII bubble? That is news to me. I thought the bankswitch logic chip was too big for a glop top so they needed a "fat" card. I would definitely have liked to see have seen more bankswitched cards though.

Nah. Here's a pic:


That the bottom side of the PCB (that faces down). The PCB is slightly longer, but there's nothing inside or under that bubble. You can clearly see the three rom chips (512k, 1024k, and 1024k, and the mapper which is the round blob). Just like the Arcade Card Duo, and that mapper is way more complex than this - still the same size (the round glop-top).

 The SuperCD ram was too little to handle a SF2 port (it needed to be at least 512k), and the arcade card wasn't finished yet (started development in 1992), so they released it on Hucard. Kind of a last huraah sort of thing.

[PCE/TG-16|CD/SGX Discussion / Re: PC Engine Pixelization]

Chunky mode refers to how the pixels are stored in memory. Chunky=linear=packed pixel format. That is to say, you can access a pixel as a single bit, nybble, byte, word, etc. Depends what the format is. It's fast for doing pixel based effects and manipulation. It's fast for rendering, as well as scaling and rotation (which is why the SNES mode 7 used this form of pixels, while the other modes do not).

El Viento just uses the BG layer to make the explosion pixels (they are the size of one 8x8 tilemap entry). Sort of how Sapphire does it for scaled explosions after a boss:


Turtles in Time for SNES also uses the BG layer for the scaled enemy when it's thrown at the screen.

Is there anything that can be displayed without converting from chunky to planar, like wire frame stuff or anything?

Any theoretical workarounds, like so many Genesis homebrewers have found to do impossible things on Genesis hardware?

Yeah, monochrome wireframe effects can easily be doable on the PCE planar format.

Planar system lends itself to transparency effects. It also allows more complex dynamic tile support (only update dynamic animation on specific planes); Ninja Spirit does this on the second level to allow the dynamic tiles to appear behind the leaves.

As far as the scaling thing, I do have a much faster routine that deals directly in planar mode (for sprites). I haven't got around to using it for anything yet. I got the idea from nesdev forum - from tepples I think. It uses sprites to advance the scaling part. In other words, each 16px wide sprite gets shrink down to 1px (all ranges in between), and instead of ORing a bunch of pixel runs together, the sprites are just horizontally adjusted to remove the gaps. It's possible to do something like a 128x144 huge sprite object with scaling at 20fps @ 57% cpu resource per frame (perfect for a boss or such).

[Localizations, Games, Apps, Docs / Re: Dragon Warrior for PCE]

I would take out the extravagance of the purple backdrop and make it a coppershade palette effect, put the hero (or dragon) and logo onscreen as sprites, and Roberta's your post-op aunt!

Hah! That's the first thing I thought too.

The image is complex though. Even as simplified, I couldn't do a lossless conversion/palette reduction.

pcedev .net/DW_PCE/new_ts_1f_show.png

(Top image is the conversion; has artifacts)
I'll have to do some sprite touch areas.

Though the Dragon and Erdrick are going to be on the BG layer, since they need finer palette associate per area (8x8). The sprites will provide the backdrop, purple copper effect, and the logo. And of course some sprites for a few touch up areas.

[PCE/TG-16|CD/SGX Discussion / Re: PC Engine Pixelization]

Nexzr - ship arriving from hyperspace..

[PCE/TG-16|CD/SGX Discussion / Re: Mega Man CD for PCE/TG-CD with new metal/rock soundtrack!]

I only tried leaving Channel 1 at the default volume and lowered the rest, but that did not make any discernible difference. Care to share your settings, if you were able to dial it down? What channel has the SFX?

It depends on the game, for which channel the FX are played on. White noise effects (static sounds) are on the last channel. But the game could use any channel for sound PSG FX. I have no idea which ones it's using (it could be using more than on depending on the sound FX).


L is left stereo, R is right stereo. Each left and right speaker has its own volume; 0 to 15. "PSG" is the master volume for all the channels. On top of that, each channel can be individually set to a volume level (which corresponds to that master volume range). If you can't get the PSG volume loud enough, after you have maxed them all to "15", then you need to edit those CDDA audio tracks to be a lower volume (you can't control CDDA volume levels on the PCE, only fading).

[Localizations, Games, Apps, Docs / Re: Xanadu II Translation Development Blog]

Finally! I can't retire from all things translations. I've waited so long... ;_; ... . .


f(x)=SamIam^3 + 2^elmer...

f'(xanadu)=3SamIam^2 + (2^elmer)*ln(2)..

[PCE/TG-16|CD/SGX Discussion / Re: SD-card or HDD replacement for CD drive?]

Well, it's so common on the interwebs.

I even made a demographic:

I'm a....vagina?

[Localizations, Games, Apps, Docs / Re: Xanadu II Translation Development Blog]

Here's pic of what 16bit wave files look like in PCE sprite format:


It's very distinct.


About 99.99999% of PCE game have junk interleaved between the data in the ISO tracks. Sometimes it's other games, or wave files, or even dev stuff (one game has the full source code to it in there along with developers notes, etc). Basically, whatever was on the harddrive at the time got copied into the ISO track.

[Localizations, Games, Apps, Docs / Re: R-Type Complete CD, anyway to add the chip music back in?]

I had the idea of trying this with Super Raiden a couple years ago, replacing the CD tunes with arcade versions...never got around to trying it, though.

I did some hacking work with Super Raiden a few years ago.


I added these options. I was able to fit two sound tracks on the disc, and the boot menu you could choose between them, as well as higher res mode, difficulty modes (include one that's harder than the PCE one, and two easy modes for not-so-hardcore shmups fans), allow skipping of the new stages (classic mode), and respawn option. I ran out of ram in the main game for respawn to work correctly, so that's why the project was halted. When TED v2.4 comes out, I'll make a compatible version for that and finally get the respawn coding bug free. It's not seen here, but there was also an option to choose which ship color to use as well.

[Localizations, Games, Apps, Docs / Re: Graphic, Sound, & Coding Tips / Tricks / Effects / Etc.]

Clipping for sprites that are larger in width of 16 pixels.

There are only two widths available on the PCE; 16 and 32 pixel wide. Anything larger is a meta-sprite.

On the PCE (and on nes, sms, genesis, snes), clipping is important because sprites that appear to the left or right of the screen, but are off screen, still count as the sprite overflow total.

Think of the sprite overflow as one large 256 pixel buffer. This includes transparent pixels as well (consoles really didn't have the luxury of only including opaque pixels). So, PCE will process all 64 sprite entries every scanline, but it's the buffer that prevents all sprites to be shown on any given line.

So, clipping is pretty easy in general. When is sprite has fully left the screen, be it right or left, you drop it from the entry list (usually set the Y coord to something outside the range, or zero out the whole entry). So the sprite (X,Y) coordinates are taken from the top-left side. If a sprite is X_coord+sprite_width <= left_border, then clip it - etc.

The obvious reason for clipping is to reduce sprite drop, or flicker if you implement it, or something along those lines. If you look at this chart here:

You'll notice that all 32 wide sprites can be easily divided into columns of 16 pixels wide.

Take a 32x64 sprite, for example, and notice the difference of how the 16x64 sprites can be defined. Normally, for such a large sprite, vram alignment is every 0x200words. If you use a "cell offset" that falls in the middle, those lower bits of the offset are clipped to force align to a 0x200word alignment in vram.

If you look at the 16x64 column specifications there, you'll see that can chose which column to address. It basically halves the 32x64 sprite into two columns. This makes clipping not only easy, but you don't need to have two copies of the same sprite... or always use 16x64 wide configuration.

So for left side clipping, you'd check (X_coord+$10) <= Left_limit. If so true, then clear X_width bit in the sprite attribute entry (bit #7, which sets the width), add $10 to X_coord, and set bit #1 of the Cell_Offset/sprite_num entry (not bit #0). Right side clipping is even easier; check (X_coord+$10) >= Right_limit, then clear X_width bit. For right side clipping, you don't need to reposition the X value to compensate, nor do you need to point to the next column.

    You can't clip any tighter than that. Something to keep in mind, though, is that the 256 pixel buffer is fixed in size. If you make the screen size smaller - that buffer size stays the same. So a 256 pixel wide screen has a 1:1 ratio to the buffer. You couldn't make a huge sprite layer/image scroll from left to right, because at certain points it would need 17 sprite cells (16pixels wide) to fill the edges. 17x16 = 272 which is greater than 256. But, PCE is extremely flexible on how you define the visible display area of the video frame. If you set the display to 240 pixels wide, that's 15 sprite cells wide. The widest scroll point of cells would be 16, not 17, and thus you could do a seamless scroll of a huge sprite (given the tight clipping I showed above). 240 pixels really isn't that noticeable from 256; some SNES games ran with this size clipped window. Now, imagine a "tate" mode vertical shmup. You could set the width to something 192 pixels wide, and fake some decent looking BG layer effects. Imagine this idea taken to the SGX? Imagine how many individual moving layers you could fake.

Or take another approach. You could make a game like Sonic, here the character is 32 pixels wide, and have the screen res clipped to something like 224 wide and clipped the vertical width with a larger display box (to make the screen area appear wider and less square). Besides a couple of key issues, you could basically create a whole BG layer of sprites.

[Localizations, Games, Apps, Docs / Re: Catastrophy! (Current working title)]

Stupid question time! I'm getting a green border on my TV. I thought this was color 0, but I must be mistaken, because I set it to 0, and it still is bright green.

Color 0 for BG is the BG color, obviously, but color 0 of the sprite index (@ $100) is the border color when no display is showing (BG or sprites).

[Localizations, Games, Apps, Docs / Re: Megaman PCE thread]

I'm not sure if I showed this, but this was the last WIP change I had made to MM:





I removed the score display, but more importantly - I added a new meter display. The green is health, and when you select a weapon the energy bar splits into two and the red side is the weapon energy. I have finished it, but below it is supposed to be a box and an icon to show which weapon is selected (MMX style). The bar is fully functional, so it's not just mockup screens. It was to do, because it's pixel plotting code. Not that I probably needed it, but the resource from removing the score display was more than adequate for the routine to work.

Anyway, all the enemies for level one are redrawn with extended colors. It takes a little bit time though, because of how I have it hacked - it has to check for every "room" of monsters (this is at the beginning of the level). So I still need to create hack tables for the other levels outside of Cutman. Probably a few full days of solid work.

Just to be clear, this project isn't cancelled. It might take me forever to finish it - but it will be a PCE-obey-fied version of Megaman when I'm done with it.

I'm also thinking of releasing the source code in intervals, as I go along. Well, for the curiously minded.



Hmm.. so slowdown is eliminated from the game simply because the PCE runs the game code faster than the NES. But these sprite hacks actually have a secondary purpose other than color enhancement; they actually speed up the game logic code because it's faster to use PCE large sprites than it is to use NES small 8x8 sprites to make larger ones. The other thing is that larger sprite cells over the native NES ones, which I've converted all sprites in the game to, also reduce the sprite flicker limit - by a huge amount! This means I can add background or foreground sprites for parallax and other similar effects. For instance in Cutman's level, I want to add scrolling clouds as a second BG layer behind the graphics. I'm also going to add a gradient sky effect via hsync. Freeing up cpu resource allows me to allocate it else where like these effects.

6 button controller support is in place already, just not functional. I'm going to assign quick weapon select for the extra buttons. Just need to receive my 6 button controller.

[Localizations, Games, Apps, Docs / Re: Ninja Ryukenden/Gaiden]

I wasn't meaning to belittle the programmers, as I was to point out the method they used. I'm interested in what makes this port feel... weird or off. I think one of the biggest things that stands out, besides the mostly inferior soundtrack (and no samples when the NES one had them too. For shame), is the depth of the graphics. I mean literally; the PCE graphics are draw to be more shallow:



Some of the other stages have a little more depth to them, but it's not as strong as the NES/famicom version. And the placement of the character and enemies relative to those "platforms" feels off. I repositioned screens for each level, and it felt closer. Of course, the gameplay in this version is fine. Some of the level redesign graphics are odd, though.

PD: Ys III has a superior engine and method to its fake scrolling. It actually rebuilds the whole tilemap (which scrolling the regs) for each frame. That's way more than Ninja Gaiden is doing. The static BG don't shutter in Ys III like they do in NG. Yeah, I know the engine is different, but Ys III is a little jerky where as NG is just broken looking (and execution of effect).

Anyway, I found the map pointer table and figured out the header format for each level.

[Off-Topic / Re: Anyone else ride?]

That's a great paint job you did, she looks much more stylish now! 

Haha ... you think 2004 is old? Mine's a 1991!  Bikes get better with a little age. 

I'm not, personally, a great fan of how you have to lean that far forward on a sport bike, so I ride something a little more upright. I avoid freeways (twisties are more fun than speed), and so don't need a windshield.

My first ride was dual sport, and was much more upright. I swapped in some clipons for a more aggressive feel and ended up loving it (felt like a cafe racer). But I've seen the exact reverse for Zx6rs; it's popular for people to convert it into street fighter style and put actual handle bars for a more upright position. I always have that option if I get tired of the supersport setup.

 Nice Bike. That tail looks familiar. What model is that?


crazydean: That zx14 is a beast. I already get crappy mileage when I open mine up, I can't imagine what the zx14 drops to at WOT. On a normal commute, I get about ~45 mpg (lot of stop and go traffic here). Fooling around, I get about ~20 mpg.

[Localizations, Games, Apps, Docs / Re: Legend of Xanadu II Translation Patch announced!]

Here's a little tease for you all ... thanks to CrackTiger's generous help, there's a new English logo for the title screen. 



If you've got a Xanadu 2 rip that runs in Mednafen, here's a savestate so that you can actually see the title sequence working with the new logo. 

dropbox.com/s/mqvx8dm23hnq8zy/Kaze%20no%20Densetsu%20Xanadu%20II

This savestate's name is right for a Xanadu 2 rip made with NightWolve's wonderful TurboRip.

You may need to rename it if your rip comes from somewhere else.

You have officially taken this over!? Woot!

[Off-Topic / Anyone else ride?]

Or used to ride?

I don't have a car, so this is my daily commuter; Zx6r 636.

I just finished repainting the bike..






This was the old color scheme:

 It's a 2004.. old by nowadays standards, but it feels like a completely new bike. Pretty much took me two weeks total to disassemble, patch and sand, paint, and reassemble. It's the first time I've ever shot automotive paint and automotive clear coat (the curved surfaces are tricky). I also did a -1 front sprocket to get a little more pep (I don't need the 170mph top speed of this bike, so the trade off was worth it). I still need a GP muffler (hate the one that's on there).


 Ride? Used to ride? Post pics!

[PCE/TG-16|CD/SGX Discussion / Re: Dracula-x unused graphics]

The 2nd image looks more appropriate. I was thinking the same thing for how the brownish sheen matches the back. That stair case isn't supposed to be next to him - it's a whole cleared area (think of the area right passed the two posts). And he can move back and forth, for the way the screen scrolls. The beam he shoots can be altered on the angle slightly too. And there are other attack sprites that go with it (a charge on the mouth area, and the floor hit spark/wave).

 Can't say if he is completely finished (AI), but all the graphics are there for him to function properly. Also, I can get the ground to show - it's just not in that pic (the map engine is very powerful, flexible and complex - so I don't understand all the variables involved). 

 I suspect he's functional, because all the assets are there as well as the map/stage layout for him. Probably taken out in near the end stage of development (why waste memory on it if they aren't going to use it? They could have used that room for other animation).

 If I could just figure out how to find/change that end of sublevel marker/variable. I've messed around with other areas, and changed to screens with 'doors' - but they don't function (or show up) either. There's gotta be some sort of 'object' map. The problem is, Konami didn't make ram as one linear layout; it's got chunks in between code, etc. So it's harder to looks for data patterns in memory (ram).

[PCE/TG-16|CD/SGX Discussion / Re: Dracula-x unused graphics]

Yeah, some sort of dragon serpent thingy.

Apparently those sprites belong to this:

[PCE/TG-16|CD/SGX Discussion / Dracula-x unused graphics]

I had this a while ago, and was currently moving stuff around.. so I figured I should share it:

This appears to be an unused enemy/monster in the game.

pcedev.net/drac-x/drac-x-1.png

Here's a look when applied to a random enemy palette:



 This wasn't just some random stuff left in the ISO (like a lot of games), but this is actually contained in the game itself. And of all things, it's loaded in vram on stage1-1. As far as I know, this isn't used in game. Unless there's a hidden area where it's used?

[Off-Topic / Re: Show us your face!]

Meh..

Fix'd.

The dude on the left looks like a young Liam Neeson / Qui Gon Jinn

Hahaahhahahahahahahaha. SO LIAM NEESON.

TANGENT:

Also, Bonknuts/TurboXray is not how I pictured him...I thought he would be far less fashionable and have glasses. I guess it's just a silly stereotype I can't shake about all TG-16 fans having glasses.

I have horrible vision, myself.  Photos are the only time I'm not wearing them. I wear prescription sunglasses at the pool/beach/lake. I SWIM IN SUNGLASSSES SO I CAN SEE TWO FEET IN FRONT OF MY WET NOSE.

/TANGENT

Heh. Glasses? Nope - perfect vision. I'm no superstar, but I have a few different styles of dress. I also ride a Zx6r (daily rider), so I'm cool like that You guys don't like my classic Nintendo jacket? I did give it to my son (he loves it). As far as the Liam Neeson comment, I'm definitely gonna have to tell Scott about that one - lol.

 Edit: Esteban, yeah more movie stuff. We got to make "one off" characters. One was "mack the knife" inspired guy (from Captain Commando), and the other was 'Heart-eyes'. And a pilot character named "Pollo".

Heart-eyes:

/10931397_643134272476223_5549533951012661984_n.jpg

^- The black sweater used for the costume, was code named "Carl Sagan" - (it was a turtle neck zip up sweater). The sweater was always referred to as Carl Sagan on set. The lights for the eyes were controllable via a small switch set from the glove (you could switch the eyes to normal eyes, and/or blink them).

[Off-Topic / Re: Show us your face!]

Meh..

My 'mack the knife' inspired costume (I'm the guy in the bandages):
(One of my characters in the movie. He's a tribute to Mac the Knife from Captain Commando)




Unmasked (I'm the one with the nintendo jacket)

[Localizations, Games, Apps, Docs / Re: The Official Emerald Dragon Translation Project]

Placeholder - History Log

** 1/13/2015 - Font Inspection Situation

Poked around the ED ROM track with a new tile viewer (YY-CHR.NET) to see what kind of font hacking is needed, found it uses a fixed-width 8x12 1BPP font, and most importantly it is uncompressed, just like Ys IV, meaning I can handle it. Otherwise, I would need David or Bonknut's help for an advanced VW (preferably) font hack job. Had to refamiliarize myself with an old tool [feidian] by D-BOY I used for Ys IV (I am rusty), but once I did and with the precise offset, I extracted the font in a viewable format. I can now insert the same font I used for Ys IV or a more medieval looking one.

feidian.php -r 8,12,16,8,0x499D5  "Emerald Dragon (J)-02.iso"  EDOrgMainFont


feidian.php -r 8,8,21,1,0x498B1  "Emerald Dragon (J)-02.iso"  EDOrgDigitFont

** Oct 13, 2014 - Talks began with David Shadoff about taking over the project

David uploaded all project materials to me, an ISO/WAV/CUE image file set of ED (ripped with *my* TurboRip I might add O:)), including 60% of SamIAm's translated results, and gave me a briefing on where the project was at to the best of his memory, etc.

Just to verify, this font is actually used in the game? Are you sure it's used for the main dialog box, and not something like the battle screen? If it's used for the main dialog box too, then that's pretty amazing find.

 As for Dracula X opening/intro, that wasn't a VWF routine. That was a replacement 6x12 font FWF routine. It's the cleanest way to hack a 12x12 print routine (which 98% of all PCECD RPGs use). It looks tight like VWF, but it's not. It's a great compromise between the two, IMO.

 On the note of pointer, like I said if the pointer system hasn't been figured out (a separate pointer table than the LZSS block), and you don't want to go through the work of RE'ing it, you can do a token system incorporated into it (making some new control codes). On that note, I never found LZSS in small block/window sizes to compress that great for English text. You guys didn't have a problem with Ys IV in this regards, or did you have to cut the string lengths down?

 The other downside to VWF, is that it takes longer to build out a character than a FWF routine. This can mess with timing in a game, which can lead to problems. I had this issue with Dead of the Brain, where I had to make special LUTs to speed things up. I'm supposed to look over Esperknight's VWF routine, but I suspect this might be happening (or a bank/page mapping conflict). Considering he had problems on the real hardware, tells me it's primarily a timing issue thing.

[PCE/TG-16|CD/SGX Discussion / Re: A realistic approach - Community driven pressed CDs]

I thought this was a Sonic and Friends free-zone? It's bad enough that stuff drifts over to sega-16, but here? -smh 

tl;dr (nothing important)


 greedostick: Actually, it is illegal. You are not allowed to translate someone else's copyrighted work and redistribute it in another language (patch or no patch). The ONLY reason why the hacking and translation community hasn't come under fire, is because this is done for non-profit AND the target audience is small enough. That hasn't stopped some companies from producing a C&D though, once a hack got waaaay to much attention (ChronoTrigger comes to mind).

 I do agree that everyone involved in a project gets veto power for their own work - period. SamIam and I are working on the translation of Spriggan, so I would definitely like it if permission was asked of both of us. I can't speak on behalf of Sam, and he can't for me.

 No one said stated that any of these hacks were made with the idea that they were to be pressed on CDs. It's not the hackers or translators problem, if you don't like CD-Rs or PC emulators (or the up and comming SDcard CD emulator for PCE that the GDEMU guy is working on).

 About the YsIV dub thing: just redub the damn thing. It's not that hard and anyone has the right to do it (there's no claim that you can't rehack or redub something just because someone else did it first). That would solve both issues for BL and NW.

To the new comers here, you're not entitled to something just because someone else released it for public use. It doesn't make it public property. You need to learn some damn respect: you can't always get what you want (I want a pressed copy of YsIV as much as any of you, even before this dub was made). Trying to justify it 3 ways around be stating they didn't have permission for this and that, doesn't negate anything. I swear some people have little to no scruples. But go ahead and do it, and see what happens to the community that wants to actually continue this type of work.

 I'm in no way against community pressings, but getting permission is the right thing to do. I feel like a broken record...

 As for Dracula X, there are like 5-6 people that worked on that (myself included). BL isn't the only one, but he made clear that he doesn't want this part used in a pressing. If you want to make your own version, you can use my tools (or rather, code) - I don't care what you do with it. But I didn't do everything in the game, and there are artists (like Fragmare) that did work too. You'd have to replace that as well. You got your work cut out for you; let's see what you're made of.

[Localizations, Games, Apps, Docs / Re: Looking for some help on a little PCE homebrew game]

Damn, I think you are far more efficient with your time than me. 

I'm only taking three classes; Algebra II - 5 credits (Algebra review, and Algebra II for cred in a single semester. Algebra II is part an accelerated course), Spanish - 4 credits, and writing 101 - 3 credits (MLA essay writing). Spanish is an accelerated 8 week course, so I'll have that free time after mid October. So full time (12 credits), but only three classes. Work is 16-20 hours a week (two days). That leaves me with one free day and some evenings free.

Neutopia III, Starring Adol Christin?

...

FUCKING SOLD!

Give me all your monies now!!! Just kidding. Neutopia III is Nodt's domain. I don't want to toe step there. That's actually the NES sprite from Ys II, recolored with the PCE scheme.

Plus, I'm a much bigger Xanadu / Xanadu II / Falcom fan. Legend of Xanadu I - I beat this game when it came out BITD (imported it, translated the game dialog as I played through the game). After beating Emerald Dragon (my first RPG import for PCE), Xanadu was my seconded. I love that game to this day. Sadly, I didn't get to play Xanadu II until decades later.

[Localizations, Games, Apps, Docs / Re: Bubble Bobble]

Added Zen-Chan and Banebou.

You're doing this in HuC? How's that working out? Old Rov and Arkhan had some speed up routines/ideas that they used for HuC - if it comes to that.

Are you going to be using Squirrel for the sound engine/fx?

[PCE/TG-16|CD/SGX Discussion / Re: Let's Talk About the Awesomeness Bloody Wolf]

I need that mug in my life! ;>_>

[PCE/TG-16|CD/SGX Discussion / Two models of the white PC Engine?]

I noticed that there are two models, or pics of them floating around the net. Is this common knowledge? And if so, which one is the original/release one? You can tell by looking at the controller port on the front. One is just round, while the other has a flat edge on the top:

[PCE/TG-16|CD/SGX Discussion / Re: Rondo of Blood Thread]

, I plan to use this for my play-through.

lol, are you serious? you need video help for the play-through of dracula x?

:edith:

sory, was already discussed 

I always like 100% completion but on second thought I'll play through a couple of times on my own.

yeah who wouldn't 100% complete drac x anyway? only a retard wouldn't. oh wait...

Lol - that response/post/pic actually made me laugh. I cringed when I saw Tats make that comment. But you took it in good sport. I give prop's for that.

[Localizations, Games, Apps, Docs / Re: Megaman PCE thread]

Saw this today: /140131020139627363.jpg (Megaman)



Pretty cool looking

Source: http://www.neogeofans.com/leforum/showthread.php?p=1207555#post1207555

[Localizations, Games, Apps, Docs / Re: Megaman PCE thread]

As in:

[PCE/TG-16|CD/SGX Discussion / Re: Rondo of Blood Thread]

In some ways SCIV is a study in how not to design a game, even people who call it their favorite game of all time tell you that you just have to get past the first  three or four levels and then things pick up, for the most part you will only have around 2 or 3 enemies on screen at once, you have far more on screen in Rondo of course, the main way you or at least most people die in SCIV from what Ive seen is from disappearing blocks and such, in Rondo its doing battle with enemies, enemy AI seems to be far superior In Rondo as well, SCIV gives you multi direction whip...in comparison Rondo gives you the ability to jump on and OFF stairs, multiple characters, different paths to choose, item crash, back flip, slide, tumble, double jump, money actually has a purpose, able to pick your secondary weapon back up, a lot of people might not know but if you keep your finger on the jump button your able to control your jump, and the turtle crash, your able to control where goes (up or down) with the direction pad.

Like I was saying before, here are some of the fx/animations that are still being used today, no other snes or genesis game can claim this. This is where Rondo of blood is the best of its generation.









here are all of the similar SCIV fx/animation for comparison..cant capture transparencies

Love your sprite rip work, awack!

[Localizations, Games, Apps, Docs / Jackal nes2pce]

I'll need some play testers.. pretty soon. 2 players simultaneous testing too (get your TAPs ready).

Download:
wayback://nes2pce/Jackal_beta_031_.zip

[PCE/TG-16|CD/SGX Discussion / Re: PC Engine Translations]

I'll look into it, I've never done a CD game before, so Brandish might be interesting.

CD games are a whole different game (pun intended), than just the base system. The biggest problem that people tend to run into for CD translations, is finding free space (ram). And if that free space will always be there through out the game :/ I soooo wanted to make a new system card, just for translations. Hell, even if all it contained was an extra 8k of ram. That would be awesome (and no, the Arcade Card doesn't provide what is needed). Though, if it's a CD 2.0 game, you can always easily 'rom expand' it to a SCD 3.0 and use the extra 192k. In that situation, it's pretty nice. I did that for Dave Shadoff on his Cosmic Fantasy I translation project. Of course, there's always the option to 'SGX' expand it. The SGX has an additional 24k of ram, that no CD game with ever touch. And for emulation, that's no problem. But for people burning a CD-r of it... well, at least I have an SGX+SCD+ACD

I have Neutopia 100% translated in Spanish.

Romhacking.net is being a bia because the "pics are enhanced due to emu"

Heh, I had no problems reading that. My spanish is getting better. I might actually play through this, for fun (and practice).

[Localizations, Games, Apps, Docs / Bad Apple for PCE]

Hi all .
A guy called stef, has made a technical demo on genesis/md, based on badapple video ..

This demo run in 320*224 with 4 gray shades and with a frame rate of 30 fps ..

You can test the 8 mb rom here :  https://dl.dropbox.com/u/93332624/dev/megadrive/demo/BadApple.bin
emulator : http://umk3.hacking-cult.org/2.11hack.zip

You can see, the original video here :

Someone can do the same on PCE ??
Personaly, i don't have skills to make the same, or equivalent .

This demo is really impressive ..

I chatted with Stef a little bit on this. While I don't care particularly about Bad Apple per se, I love the challenge that it presents. I mean, it's within the real of do-ability for quite a bit of systems (including the 8bit lesser systems) - but it's about getting the most you can out of the system to display the best version. Coming up with unique compression schemes to get it to fit in the required space is fun (IMO).

Anyway, I looked into this last year. I started writing a compression system for 3 color version for the PCE. PCE can be put into 2bpp tile/tilemap mode, which is 4 shades/colors but 3 colors/shades compresses better. I was doing a 256x192x30fps version.

This:

I got compressed down to $327 bytes. It can be compressed further, but I didn't finish the unique compression for this type of images.

I had originally planned it for the SF2 extended mapper (8.5 megabytes), which mednafen emulates. But I also wanted to do a 2.5megabyte version as well (original SF2 mapper).

PCE has some advantages:
-Planar format for tiles means simple compression schemes are faster to decode.
-Planar format can be selected for 2bpp display, reducing the amount of bandwidth the cpu needs to write to vram (i.e. no padding needed, so no express overhead)
-you can write to vram during active display
-you can also do a 1bpp version too without padding to 2bpp. Since the VDC has a latch on the MSB of the vram data port, you can just write to the MSB and ignore the LSB (you need to write zero here once and that's it). Instance bandwidth cut in half.

Some things about huvideo; Gulliverboy runs at 10fps, but that's at 4bpp tiles. If you set the vdc to 2bpp mode, for the same bandwidth to the VDC *and* from the CDROM - you can instantly do 20fps for 2bpp. And 40fps for 1bpp. The space required for the palette map and the palette data itself inside the huvideo frame can be allocated for more tile data - thus increasing the resolution as well. So a 1bpp version at 30fps could totally be possible at a decent resolution (higher than Gulliverboy).

[PCE/TG-16|CD/SGX Discussion / Re: Bible PC Engine Volume 2 (in french)]

Isn't it beautiful?

This is sooo omelette du fromage! I want one.

[PCE/TG-16|CD/SGX Discussion / Re: So there's this Dino Force alpha version...]

This is from Gekkan PC-Engine magazine 9/1991:

Heh, with a weapon like that... it would flicker like a biatch.

[Localizations, Games, Apps, Docs / Re: Question about sprite layering on the PCE]

Note, the following sprite is not mine, I "modified" an "Advance Guardian Hero" sprite to use as an example.

Could the following character sprite set up be done on the PCE?



Meaning one whole character sprite made up of three pieces. Isn't that what the second Toumaden game does?

Assuming the  upper torso frames *never* overlaps the leg frames (even by a single pixel), the gun is overlapping both. So at any point the gun sprite is taking up 4 slots (16x16 sprite slot) for a total height of 16 scanlines (the torso needs a minimum of 32 wide sprite for the most of it and same for the legs). That's 64 pixels or 1/4 the total allowed sprite pixel bandwidth for that given scanline. That's very wasteful IMO unless you specifically NEED to do this. If you're trying to build out more complex animation based on 'section' animation for sprites, well.. I'd probably use ram to pre-composite them at the start of the stage or when an event changes. The method of overlapping sprites is pretty popular in arcade game design at the time of the 16bit era, but they had a lot of sprites to throw around per scanline, so it wasn't a big deal.

 Either waste the rom/cdram space for the precomposite frames, or composite them yourself (code) into a prebuild sheet when needed during runtime/downtime/whatever-time. Otherwise (like others have stated), you're gonna waste through your sprite scanline bandwidth.  Also remember, flicker doesn't happen unless you code it to happen (sprite priority shifting). Sprite cells (16x1 resolution, not 16x16) get dropped when sprite bandwidth is exceeded for that scanline. The lower priority sprites in the sprite table (SAT) get dropped over the higher priority ones (earlier entries in the SAT). The priority flag of the sprite to the BG layer has no effect on this either (they're all treated by what number they are in the SAT - nothing else). Remember, that means *non* visible sprite pixels too! If you have a sprite object that only takes 6-8 rows of consecutive visible pixels in that cell, the rest of the rows still get 'calculated' into the sprite bandwidth for the scanline they land on.