Complete HE-MAN 2019
- Thread starter ABK
- Start date
Project is completed.
oldyz
Well-known member
Karl Jablonski said:
are you using any flightstick or wheels, or wiimotes or gamecube adapters?
sometimes other controller drivers interfere with openbor's mapping of other controllers (you get sticks functioning as buttons & other weird stuff)
you have to figure out how to disable the drivers before mapping Openbor's buttons (or just uninstall them)
Also make sure that bumpers & analogs a calibrated, because any slight pressure on anything analog activates a mapped button.
Its better to use the digital cross & digital bumpers.
bWWd
was the decision to be able to choose the same characters on purpose, or is it because there seem to be currently no way to activate nosame for players 3 & 4?
(its weird to play as 4 he-men)
Patrickbeyondthetoonroom
New member
I accidentally deactivated my controller options on He-Man and I was wondering is there a way to get it back?
Patrickbeyondthetoonroom
New member
I have an idea that you can maybe do skins of alternate characters, like He-Man as his 2002 version, New Adventures, and the live-action movie.
Patrickbeyondthetoonroom
New member
I'm playing it on Playstation Classic using Auto Bleem as I just installed the .pak.
I just downloaded the Crono Crash version from here and I may have to delete the .pak I got from the maker's site and replace it with the one here.
I just downloaded the Crono Crash version from here and I may have to delete the .pak I got from the maker's site and replace it with the one here.
hey patricktheshortestusernameonchronocrash that idea about different versions dont click with me, i dont like new adv and heman from 2ks has mehhy designs but good scripts for storyline, i only like filmations heman.
Butbi did make mattel figures version of heman sprites and skeletor , i like that.
Butbi did make mattel figures version of heman sprites and skeletor , i like that.
Patrickbeyondthetoonroom
New member
bWWd said:
I'm okay with that. Maybe for an update, I like to see Bravestarr, Blackstar, and maybe a few other 80's cartoon heroes as DLC. No Transformers.
John_Couey
Member
yeahhh the old idle animation is better from my perspective.
Toranks
Active member
Yes, I prefer the old one too, It is less exaggerated, and does not seem to be dancing instead of doing a battle stance. Although it would still be interesting if you combined them in some way. Is it possible to have two different idle animations randomized, or the new one run first, then the old one indefinitely until you walk again? It would make it quite interesting like that.
Youre right, i know about this, its slowing down on android devices and i have to figure out another way to create this level, theres too many entities/walls , i should merge the ones that are on the same Z axis to save some memory.There is 18 rows , so i have to reduce all entities to 18 .Currently there are 120 entities at once 
It means that entity graphics needs to be 3800 pixels long, im not sure if this change will save memory... entity count will be smaller but actual graphics would take more kilobytes of memory.
Damon Caskey can You elaborate whats the best solution ? Labirynth stage is built from small blocks of walls, single entities each with platform command in idle animation to create pathways and block the area, would it help if i would conver each of 18 rows to single entities, some of them would have to be like 3800 pixels long instead of 450 pixels.So maybe its multiple platforms that create the slowdown , not actual entity count ? ( OK i tested it, it doesnt make any difference if platform code is in idle or not, its still slowing down)
Will this change relive cpu from performing and fix the slowdown noticeably ? Is if worth it ? Or whats the best solution to create this kind of level ? Each wall must stop players and enemies to walk through it.
It means that entity graphics needs to be 3800 pixels long, im not sure if this change will save memory... entity count will be smaller but actual graphics would take more kilobytes of memory.
Damon Caskey can You elaborate whats the best solution ? Labirynth stage is built from small blocks of walls, single entities each with platform command in idle animation to create pathways and block the area, would it help if i would conver each of 18 rows to single entities, some of them would have to be like 3800 pixels long instead of 450 pixels.So maybe its multiple platforms that create the slowdown , not actual entity count ? ( OK i tested it, it doesnt make any difference if platform code is in idle or not, its still slowing down)
Will this change relive cpu from performing and fix the slowdown noticeably ? Is if worth it ? Or whats the best solution to create this kind of level ? Each wall must stop players and enemies to walk through it.
bWWd said:
bWWd,
Before I say anything, I want to iterate the first rule of optimizing, benchmark. Basically, it means no matter how logical it might seem looking at code, you never know if an optimization will work until you test it. There's no "benchmark" tool for OpenBOR modules, so real world testing is your only option.
Logically, reducing the number of entities will reduce the engine's load, and here's why:
Whenever there is a platform or wall on in the level, the engine is always checking against it. The computer can't think like a human and go - "oh, well that player is on the other side of the room, I don't need to run calculations to see if he's touching this wall/platform." There are some complex algorithms you can add to try and do that, but they have their own problems and that's another discussion. Worse, OpenBOR uses floating points for its platforms and walls. You'll note Roel pointed out he avoids them in his platform games. Floating points are expensive (but they are needed for precision since OpenBOR is a 3D world).
In short, walls and platforms are expensive. But, here's the upside - it's a fixed expense per object. Unless you you get into ridiculous number ranges, it doesn't matter if a size is 500 or 5000. The formula is the same and you won't notice any difference.
On the other hand, every time you put an object on in play, OpenBOR has to add it to some check loop. More entities - more iterations. More platforms, moar iterations. In the case of walls and platforms, each being a fixed expense.
IOW, yes, you should be better off with fewer, larger, walls and entities than tons of smaller ones. I would also prefer walls over platforms when possible, because no matter how much you optimize them, platform entities still have a lot of unused logic running. But back to the first statement - just because it makes logical sense doesn't mean that's what will happen. I know it could be work for nothing, but my suggestion is rebuild with larger objects, and test it vs. the old one to be sure.
If that STILL doesn't work, I once experimented with a scripted concept that spawned and destroyed fixed entities as needed to keep them out of play when they weren't on screen. The script itself was fairly expensive, but it was a big net gain overall compared to leaving everything in play at once. I ended up scrapping it because for me it was just unnecessary complexity, but it could be something to think about for you.
DC