Archive for the homebrew Category

A few old utilities..

Posted in homebrew, PCE PC tools on April 15, 2016 by pcedev

I have a few private utilities that I’m seriously thinking about cleaning up and releasing to the community. One is a palette sorting utility for PCE’s subpalettes and pics. It’s not as fancy as say Image2PCE or Promotion, as it doesn’t generate lossy¬†results, but it does seem to get better results with its sorting algorithm. In other words, you can feed the output of either program and crunch the number of subpalettes down. What I found that works the best, is Promotion and setting the color limit for each tile to 15 instead of 16 and allowing my Pic2PCE app (for a lack of better name) to re-crunch the image again. It also works great with utilities like Mappy: export a tileset, use this utility to sort all tiles into proper subpalettes and then encode them (the colors of the tiles correlating to the subpalette number) into ranges of 16 colors inside a 256 color block (thus 16 subpalettes). This isn’t too useful on it’s own, but I have another powerful Mappy conversion tool that can extract this information. It does all kinds of nice things with the FMP file for conversion, include clipping X and Y ranges (great for making mappy prioritize tiles to specific slots; aka dynamic tile animation), as well as stuff like vram offset, subpalette offsetting for tilemap, output horizontal or vertical strip format, use additional layers in the file to create collision or object maps, conversion of 16×16 mappy files into 8×8 with LUT, not LUT, or native 8×8 support, etc.

The Pic2pce app has an internal GUI already. I’ll be adding GUI support to some of the other apps as well, since I’m work on this area of stuff for the DIY Shmup suite, but you can still use command line arguments for batch processing. I think it would probably be a good idea to make some video tutorials for how to use these tools, too.

SHMUP suite musings

Posted in homebrew, Uncategorized on April 7, 2016 by pcedev

I have two issues. One, is that I don’t want to have to learn a GUI setup for windows in order to make my utilities. This probably the completely wrong approach to a solution; reinventing the wheel. But I’m soo used to it. Ok, here’s how I’ve made my GUI-ish apps in the past: it’s all internal. My GUI needs have always been simple. I just need a few buttons, and a display windows. Nothing fancy, nothing much. I currently just create the buttons and layouts manually. Yes, that means providing the X/Y coords and which functions they correspond to. I’ve decided that if I’m not going to actually use an existing GUI toolset, I should at least create my own toolset for creating GUI frames. Duh! So I’m doing just that. Just a simply visual editor for placing buttons and display windows. That gets compiled into a text define file which I can include into my code and just associate functions via pointers, etc. This probably makes some people cringe, but I think it’s fun.

Secondly, enemy¬† pattern AI. Well, AI might be a strong word here. Reactive might be a better word for it. But that aside, simple dumb enemy pattern movement.. how do I make this flexible enough that people using the suite don’t have to rely on a list of fixed pattern movements? I’ve taken a cue from the FM playbook. Enemies can be defined by phases. Inside each phase, there are three operators. These operators are a type of behavior; sine, cos, etc. You can assign where the output of the operator is going, X or Y coords, or as a modulator for another operator. Each operator also has assigned attributes like frequency and scale control. The phase has two attributes: time and reaction. The time parameter is self explanatory (how long the current phase lasts), the reactive parameter is a little different. It could something as if the enemy gets shot (doesn’t die in one hit or does and spawns a new objects, etc), or if the enemy gets close enough to the player – change phase. This might sound expensive on processing time wise, but really it’s not. Of course there will always be predefined patterns designers can default to (familiar enemy patterns), to keep resource lighter for the bulk of the level. It’s all about balancing where the ‘spice’ is anyways.

I’ve been playing around with other idea of how to emulate the PCE video and audio in the simulator. This is easy enough, but it’s tied directly to the game engine and not the real PCE. So I’m not worried about accurate emulation – just enough simulation for the game engine. The audio part is going to be tricky for me, as I’ve not had a whole lot of experience with it, but I’m sure from the little that I have done on the PC – it’ll be fine. Again, not really emulating the PCE’s audio as I am simulating it for the chiptune and SFX engine. In my opinion, that’s pretty big difference (and in favor for my side – lol).

Email and file server is down

Posted in hacks, homebrew, NES2PCE, retro on October 17, 2015 by pcedev

My server account got suspended cause I didn’t pay the bill. Hopefully I can get it back online in the next few days.

I’ve been messing with PCE hardware this weekend. Also looking over what projects are due, what needs attention, and what is going to be put on the back burner (for time resource reasons).

That and just some gaming on the SGX+SCD. I was playing SMB (nes2pce) and realized I could optimized some of the nes2pce PPU emulation code. Anytime the cpu writes to vram, the internal emulation code has to do all these checks to make sure it’s transferring data to the right area (and how to interpret that data). I needed this because I found games could just load PPU tile, sprite, and tilemap stuffs all in one shot.

Of course this slows things down having to do all these checks. Sometimes it puts what would normally be the cpu in vblank time, into the start of active display. I figured one way to speed this up, is to have dedicated $2007 write functions. NES games tend to setup strings of data into a buffer to be updated during vblank (because game logic is processed during active display). This means it’s very rare that a string of data will cross a tile bank into a nametable area, etc. So for those areas of code, I could potentially use the faster and specific $2007 write functions.

Nes2pce code was never meant as general emulation for NES games to run on the PCE. It was to get the game up and running close as possible, to help the transition of replacing the original NES sprite and map routines into native PCE stuffs. Though none of the nes2pce stuffs I’ve released have these changes.

Ideally, the sprite and map routines should be hacked for direct PCE writes, by passing some of the PPU emulation. So the optimization I listed it kind of counter intuitive to the goal of nes2pce. But I just don’t have the time to alter each game for these kinds of changes. I used to have that kind of time, but I squandered it :/ Eventually, I will have that kind of time again – but will people really care about nes stuffs on PCE by then? One example is Dragon Warrior. It’s the first RPG I’ve ever played, so I have nostalgia for it. I’ve already hacked the map routines somewhat. The game is simple enough to keep modifying. But should I really put my time into it? This is the dilemma I’m faced with nes2pce.

Anyway, just thinking out loud.


Posted in Game 2014, homebrew on August 27, 2014 by pcedev

I added some more functionality to the queue processor. I ran into a bug that would add a process, and reorder the queue – but it was called inside another running process. This caused and infinite loop. Now, I added a process manager at the end of the queue. You push a process request on the process manager queue, and it’ll perform the actions needed, outside the queue itself.

For instance, in-game (player) controls is a process in the queue. It runs when in game engine is running (there are other control/input processes for different ‘windows’ or other parts of the game). The process reads the input of the buttons. For certain button action, a new process might be pushed onto the queue. Processes can remove themselves, and they do. If the player pushes a certain direction, and a screen edge, or stairs, etc is encountered – it’ll call a scroll or warp process as needed.

I do the same for action events. I’m implementing the basic attack process this week. The button detection logic ran inside the game control process. It would push the attack process into the queue, but I did this with a priority level request (rather than just anywhere in the queue). This just happened to be above the current process (game controls). Causing the game controls process to be re-run on the exit of that process. No good. Instead, and much better design, I implemented at request system that happens outside the queue. Much safer.

Now back to working on attack code..

Posted in Game 2014, homebrew on August 25, 2014 by pcedev

Some show-off stuffs:

It’s not for showing off the graphics, but the map/area system. I can scroll between screens inside of areas, but also to scroll/link to screens inside other area maps with other assets (the fade in/out to load new assets). And of course, warp points (stairs/doors/etc).

Posted in Game 2014, homebrew on August 23, 2014 by pcedev

Hah – doing a major rebuild of the area:screen system. An area has a specific tileset and palette for up to 256 screens (16×16 screen block). I could, in theory, have 256 areas (1million pixels by 0.720million pixels).

I needed more flexibility in the design of things. I needed a way to better organize map data too. Warps/stairs/etc can trigger load of near area blocks – which requires a screen fade out and in. Of course, edge screen exits can do this now, too. So, transitioning from a forest to a desert – is a fade transition allowing new tiles to be loaded, instead of the normal screen scroll.

The down side; I’m rebuilding a lot code screen fetching code. School starts this Tuesday (full time), so I’m trying to bang out some code over the weekend. I have some new test maps/tiles that I want to try out, but they require this new code.

Composting tiles

Posted in Game 2014, homebrew on August 23, 2014 by pcedev

I was looking at a lot of graphic tiles sets and such. If you done anything with new 2D engines (especially top-down), you’ll notice that a map will reference objects instead of tiles. PCs and such and limited to square tiles. Basically the objects are composited/overlaid on top of the map.

Normally, you hard-composite all these kinds of stuffs into regular tiles on these older system. This wastes a lot of space in rom, and eats up vram. For system that have more than 1 BG layer, you kind of do a half process and let the system composite the layers in realtime (saves on vram and rom). Not only does the PCE not have this, it also lacks flipping modes for tiles (instead, it got more subpalettes – only so many bits can fit into a tilemap entry).

My game scrolls screen-to-screen. This lends to the advantage that I could do real time compositing for a full frame before the screen starts to load. This would allows more unique looking detail (less pattern-y), and it wouldn’t stress the cpu since nothing is going on during screen scroll and a full frame or two is pretty decent amount of time to throw at this. There is a down side; I ~do~ scroll between screens instead of just snapping to the next. This means I need room for two screens of unique tiles. I do not have enough room for that. The compromise would be: use a base set of tiles for the ‘area’, but allow a two small buffers for unique tiles for the screen. Two buffers, because I still need to scroll between the two.

An example would be field grass. The grass would be the base, and I could overlay other objects on top – small rocks, or different patterns of flowers, unique edge transitions into other material, etc. The grass could take up 4-5 colors and the rest of the color slots in the 16 color pool would be set for the composite material. This is where the PCE’s huge amount of subpalettes comes in. You could probably apply this idea to actually scrolling maps, but the implementation is more complex, but still do able.