openBOR character hitboxes shifted?

[Zero]

Hello,

I've been playing around with the BOR source lately (original build, not openBOR), looking to port it to yet another system.

Used openBOR to do some very basic characters debug, and I've found hiboxes are apparently shifted up by 2 pixels in openBOR.

Is that an intended change/fix, glitch, or just a box debug display issue?

See pic, intended boxes vs ingame boxes:

Also, that 160 position characarter seems to be displayed at 156?

Thanks 

 

[O Ilusionista]

looking to port it to yet another system.

Which one, may I ask?

 

[DCurrent]

...

If there is an error, it's in the debug display, not the hitboxes. The math to transpose 3D world coordinates (which the boxes operate on) to 2D screen coordinates is very tricky. It's made even more tricky by the fact the actual coordinates are completely different from what you put in the text files. I probably just loused it up a little.

DC

 

[Zero]

...

If there is an error, it's in the debug display, not the hitboxes. The math to transpose 3D world coordinates (which the boxes operate on) to 2D screen coordinates is very tricky. It's made even more tricky by the fact the actual coordinates are completely different from what you put in the text files. I probably just loused it up a little.

DC

All right, thanks.
What about the center dot tho?
Looked at some original BOR videos, characters are definitivelty displayed a few pixels lower.
Not a huge deal breaker anyway, just trying to stick to how it should display/act 

looking to port it to yet another system.

Which one, may I ask?

Currently investigating options for a neogeo port.
It will come down to how well the system can swallow the engine tho, its time based nature isn't very well suited for frame based older systems. (having to update entities multiple times per frame instead of once). Also floats of 68000 = dead slow.  :-\

 

[DCurrent]

Currently investigating options for a neogeo port...

I'm afraid you're in for an uphill battle. For all its hype, the Neo-Geo is a pretty limited architecture that's utterly incompatible with BOR. BOR more or less runs on a brute force approach.

• Sprites are loaded and displayed whole. There's no form of stripes, blocks, or compression.
• Most stages have three layers, some have up to six. The Neo's biggest weakness is a lack of tile layers. You'd have to burn through most of your sprites just to make the backgrounds work - especially the water levels.
• BOR makes heavy use of alpha transparency in stages, which the Neo does not support at all.
• Unlike OpenBOR, the original BOR has no form of memory management. Assets are loaded in order they are encountered... that's it. Reuse a sprite? Nope, it takes up another slot in memory.
• There's a ton of shifts and bitwise operators in play, many of them against unsigned 32bit ints. If the Neo's bus doesn't like that, you're in big trouble.

TL;DR: The Neo simply doesn't have the horsepower to run BOR as is. It can certainly replicate the game, but by then you've essentially built a Neo-Geo game that happens to look and play like the original BOR. At that point one has to ask WHY? As a stand alone beat em' up, BOR pretty much sucks rocks. Its modability was the main selling point, and you'll have to lose most (if not all) of that to make it work.

DC

 

[Zero]

Well in fact I have the core of the engine already running after a couple days adjusting a few things and making tools to cook the data. Who needs memory management when you have everything  available in rom? 

(don't mind the incorrect palettes)

My main concerns are sprite load on the most intense sections, and pure engine logic cpu load.

Backgrounds seems ok after a quick glance, looks like maximum two layers in the original game, water can be done with a raster interrupt. Of course sections will need some adjustments to fit tile alignment/palettes requirements. Rework/drop a few transparent elements/mirrors.


I know it's not the best game out there, it's just for the sake of brewing up something/challenge 

 

[DCurrent]

Well in fact I have the core of the engine already running after a couple days adjusting a few things and making tools to cook the data. Who needs memory management when you have everything  available in rom? 

HAHA, good point. I completely forgot about that. Life is easier when all your assets are sitting on fast ROM. 

Backgrounds seems ok after a quick glance, looks like maximum two layers in the original game, water can be done with a raster interrupt. Of course sections will need some adjustments to fit tile alignment/palettes requirements. Rework/drop a few transparent elements/mirrors.

Don't forget the foreground - that's your third, and water makes a forth. Technically there are six layers (front, main panel, neon panel, transparency panel, water, and background). All the panel types are locked together, so there's really four independent layers. I can't recall if the game ever uses them all together, but I do know there are stages that have a front layer, panel, and background. Just a fun FYI, OpenBOR has unlimited layers and panels - 50 layers of clouds? Yes please!

I know it's not the best game out there, it's just for the sake of brewing up something/challenge 

Fair enough!  ;D

 

[O Ilusionista]

I don't want to piss on your crop, but I don't really see a point in porting it to MAME or NEOGEO at all. Both engines can be run in desktops.
I can see a point when you port to portable or different consoles, like PSP, OUYA, DS or even Retropie (Linux). Or helping us to compile it for forgotten ports, like MAC.

But I wish you good luck.