Pocket Dimensional Clash 2

Complete Pocket Dimensional Clash 2 2.3

No permission to download
Overview Updates (5) Reviews (5) History Discussion
Project is completed.
Note: Oops, it looks like we forgot to turn the enemy info (icon, name, and health bar) back on when we recorded this video.
We’ve fixed it now—that info will always be visible; personally, I’ve never liked beat-'em-ups that don't show it.
 
Dude, I'm always dying for having an animated subscreen for huds, but I struggle.

Looking great, man! I really like the animated subscreens with animated hearts playing as a lifebar as well as the animated MP bar.
 
maxman said:
Dude, I'm always dying for having an animated subscreen for huds, but I struggle.

Looking great, man! I really like the animated subscreens with animated hearts playing as a lifebar as well as the animated MP bar.
Click to expand...
It was @DCurrent 's wizardry. I look at the code and understand almost nothing, haha—and that’s even with it being fully documented and organized.

He can explain it better, but as far as I know, each heart is a subscreen too, just like the MP bar.

We use additional subscreens on the selection screen as well—one for the portraits and another for the character and game names.
pdc - 0085.png

And the select screen works in-game too:
pdc - 0086.png
 
  • Like
Reactions: NED
O Ilusionista said:
He can explain it better, but as far as I know, each heart is a subscreen too, just like the MP bar.
Click to expand...

The individual elements - hearts, meters, icons, text, etc. are not sub-screens, but HUDs, the scrolling background, and the "pipes" are.

Before explaining the layers, there are six sub-screen basics worth knowing:
  1. Items are positioned relative to the sub-screen. The hearts, for example, are arranged within their player’s HUD panel. Moving the HUD means moving its screen. Everything inside moves together and keeps its layout.
  2. Width must be a multiple of four. The engine rounds the requested width down when necessary. Height is used as supplied.
  3. Drawing order determines priority inside the screen. Later draws cover earlier ones. The completed screen receives its own Z position in the main sprite queue.
  4. When background transparency is enabled, RGB (0, 0, 0) pixels are transparent. Disabling it makes those pixels draw as black.
  5. Pixels stay until you overwrite or clear them. Unchanged screen contents can be reused across frames.
  6. Each screen submission occupies one entry in the engine’s 5,000-item sprite queue, regardless of how many elements were drawn into it.
The first four guide construction and design. The last two provide opportunities to optimize.

For handling logic, the HUD system leverages OpenBOR’s ability to compile scripts on the fly, giving each HUD its own self-contained script instance. The script builds its display within a sub-screen, while the manager handles its placement. Contrary to popular understanding, OpenBOR very much supports object-oriented programming and polymorphism - we’re using both here to build independent HUD objects with their own state and interchangeable implementations.

Each player slot owns its renderer instance and private meter data. Characters use the default renderer unless their model specifies a custom script. Multiple players can use the same script source while maintaining independent display state. This lets us customize one character’s HUD or reposition a complete panel without rewriting the surrounding system.

Once everythign is ready, it gets composited onto the sub-screens. From back to front, the current arrangement has four layers.

1. Scrolling backdrop

The backdrop uses a 480×56 sub-screen at X 0, Y 216. The scrolling texture is tiled into it first, followed by a stationary mask that writes transparent black over the unwanted areas. The completed screen sits behind the player HUDs.

2. Individual player HUDs

Each player has a 108×44 sub-screen at Y 228, with X positions of 11, 128, 246, and 362.

Each renderer reads its current actor’s information and draws the applicable elements. Meter sheets define the layout, value sources, and display conditions; a support library called dc_filmation supplies the animation artwork. This produces the hearts, MP gauges, portraits, names, scores, and other contents of each panel. Both the HUD and dc_filmation leverage the engine's ability to read files. So instead of hard coding animations and layout, they both use sheets that I designed to be very similar to the engine's native text files:

Here's a snippiet from the animation sheet - the belt scroll for HUD background:

Code: 
# Shared full-width HUD layers. The pattern repeats every 32 pixels.
# Filmation applies belt_notch after returning to the minimum, so -1
# produces a 0..31 loop.

animation player_hud_back_scroll

    belt_delay 32
    belt_loop x_return y_return
    belt_notch 1 1
    belt_position -1 -1 31 31
    dm_config active reset_pre reset_post
    dm_enabled 1
    frame data/sprites/hud/player_hud_back_a_0.png

3. Pipe bezel

The bezel uses another 480×56 sub-screen at X 0, Y 216. Its shared pipe artwork frames all four player panels. Keeping it separate lets the frame stay stationary while the backdrop scrolls and the player displays change. The renderer also supports animated framing artwork.

4. Native HUD text

We let the engine's native HUD supply the credits, “Game Over,” and “Press Start” text. Everything else is moved offscree to disable it. It would be pretty easy to handle this part with custom elements too if we wanted.

HTH,
DC
 
Here is a rundown on the selection system...

The selector uses a flattened indexed array of 72 slots, representing 18 columns * 4 rows. Each occupied slot stores a pointer to the model’s database record.

The model database reads the model sheets, and selection logic uses that information to determine eligibility and placement. Models can specify their own grid coordinates, and those positions get priority. The remaining eligible models fill available spaces from left to right, row by row, within columns 1 through 16.

Reading and parsing all those files is slow - really slow in computer terms. Preparing all the data takes about 0.25 to 0.5 seconds on a low-spec machine. That's a lifetime in live play, but a microcosim in loading, which is where we do it. To make it even less noticable, we spread that work across the loading routine, adding records as models become available and skipping those already processed.

Then, once the data and selection array are populated, it’s brutally fast. Player browsing, random selection, and other selection operations work from optimized records already in memory. Combined with reusing the finished sub-screen between changes, that lets the selector run during live gameplay with no worries at all.

Drawing the grid​

The visible grid is a single sub-screen containing the striped background, grid lines, model icons, player cursors, and control instructions. Each icon’s position comes from its cell in the array, with coordinates relative to the sub-screen.

Highlighted icons appear in their original colors, while the others receive a darkening tint. The outer columns, 0 and 17, receive background fill and borders only when a player highlights a cell there.

Reusing the finished picture​

The grid’s contents stay static between selection changes, so we only rebuild the picture when its display state changes, such as when a player highlights another model. Plus, as noted above, a sub-screen is one item in the sprite que. So even though we've blitted several dozen elements to the sub-screen, the final draw is just one sprite.

Masking unused cells​

During live gameplay, the renderer draws RGB (0, 0, 0) boxes over empty cells after drawing the background and grid lines. Remember the sub-screen transparency rule: those zero-valued pixels become transparent when the completed screen is displayed, revealing the gameplay underneath.

The renderer restores the borders of occupied cells, then draws the icons, instructions, and highlights. This keeps the selection overlay’s visible footprint limited to the space its contents need.

ss_diagram_0_b.png

HTH,
DC
 
Looking at the character select screen, I got the impression that you should be able to navigate up, down, left, and right, much like in MUGEN or other fighting games. Is it actually limited to just left and right selection?
 
A new character has been added to Pocket Dimensional Clash 3—and this time, it’s an original one: Crafty Coyote, bringing Darryl Flood's character to life.

We’ve always wanted to bring a boxer into the game, and now we have one :)
Full video:
 
Jhfer—my longtime partner who, besides being a great friend, is a walking encyclopedia of comic books—is constantly working to bring new characters to *Pocket Dimensional Clash*.

I know some people might find it odd that he’s creating content for *PDC4* while we’re still programming *PDC3*, but he always works ahead of the curve, and we like to plan things out; we almost never add a character just for the sake of it—unless we really love them.

This time, he’s bringing not just one, but two new characters. Can you guess who they are?
new_char.png
Hint: They’re from comic books, and from rival companies.
 
You must log in or register to reply here.
Back
Top Bottom