OpenBOR v3.0 Build 4316 (Windows/Wii/Android)

Status
Not open for further replies.
Ok, now I'm working on:

1) fixing offset labels in options
2) please test noise sound on wii. test version: http://www.mediafire.com/file/cl9yydz298rt52d/openborWiitest.rar
3) magggas your bug is from 4316. but latest working?

jaythompson said:
Is there any intention of fixing the more that 4 gamepads issue? I would love the ability to turn off gamepad support altogether so I can use my keyboard. I'm trying to run this through an arcade cab that has more than 4 gamepads seen by Windows. I could map keyboard keys to my control panel joysticks no problem but OpenBOR refuses to load with that many gamepads attached and unplugging gamepads to play is not an option in this type of set up. Thanks for the hard work you guys do on this!
Click to expand...

Did you check latest openbor build to check if  SDL2 2.0.5 fixed the issue?
 
White Dragon, I'm already reworking the menu code. You can mess with it if you want, but it might be a lot of work for nothing because all that stuff is getting a redesign anyway.

DC
 
Damon Caskey said:
White Dragon, I'm already reworking the menu code. You can mess with it if you want, but it might be a lot of work for nothing because all that stuff is getting a redesign anyway.

DC
Click to expand...
Ok, but I fixed all offsets for labels in option menu (maintaining the used style), please  overwrite only if required.


OpenBOR v3.0 Build 4328 (Windows/Wii/Android)
https://sourceforge.net/projects/openbor/files/OpenBOR_v3.0_Build_4328.rar/download

Updates from 4316:
-new animationscript if full compatible with all mods.
-reworked debug coords display (by DC)
-rand32 returns positive/negative rand number
-add srand(seed) to script
-fixed options menu and joined cheatsmenu into optionsmenu to avoid to re-enter in menu to find cheats
-fixed label offsets in option menu
-fixed crash when active all debug options i levels with many entities.
-fixed debug coords display when actived performance debug options.
-reorganize menu functions with Big-endian style naming (by DC)
-added jumpspeed in entityproperty
-added nodebug in models.txt. set nodebug 1 to disable debug menu in options
-test MAXQSPRITES 1000 (just for testing). it should not make heavy use of resources. (dont worry DC, just for test, I need some feedback).
from what I see this define is just a protection. the increase should not make heavy memory usage.

Ps. DC did you solve maggas issue? any changes to pathfind code? Maggsas check your code please.
Ps2. please test noise sound on wii. test version: http://www.mediafire.com/file/cl9yydz298rt52d/openborWiitest.rar
 
Tested build 4316:

- Random bug is gone, thanks!
- Flickering bug doesn't happens right when I start the stage
CwpYI0o.png


but when I use War Machine's hyper move, the flickering returs
NnoC79H.png

btw, rounded positions are way better.

Nice work, guys. Just little fix here and there and its good.
 
Eheh, well. The flickering effect depends from sprite limit.  So 1000 is not a good value..
You tested 4328 not 4316 right?
I'm working for a stable build. From date when I started to work on openbor. I don't want bugs or uncompleted features. Just or black or white!
 
OpenBOR v3.0 Build 4330 (Windows/Wii/Android)
https://sourceforge.net/projects/openbor/files/OpenBOR_v3.0_Build_4330.rar/download

Ok Magggas, found tha issue...
not a bug in reality...
There was a small change in the detection logic of the walls/platforms (by me).
Very often have I had to upgrade my game on logic changes of the different openbor builds ...
sooner or later, in any case, to changes of Engine you will have to undergo changes in their mod.
But this time (for now) we probably solved. Try!
 
magggas said:
Well ok, for a fourth time(i think), the enemies are fliping around like crazy when they try to chase weapons. I have even already posted 3 videos where you can see it very clear. And again, this happens in other mods too. And also again too, the latest working build without problems was OpenBOR_v3.0_Build_4185.

And the only thing fixed on the latest OpenBOR_v3.0_Build_4330, is the climbing issue.

I hope that this time you will really read the full comment, because i will not gonna answer the same questions again and again, like "in which version is started?" or "But I'm what case? no sufficient info".

And something last: I is clear that you throwed too many changes and new features in a very short time. Which means you could not have tested for compatibilities or bugs causing in the engine. So, stop blaming us and advice us to check our code. You guys have first to check and test very well every new feature you adding to the engine, and not throw in 10 new features every day without really testing what else they may be affect.

So as much as i appreciate your work guys, i'm still done with this.
Click to expand...

Not simply to test that bug, because it depends from the mod code too...
like climbing. not blaming you but we cant know how you code can work...
BTW checking...

O'Ilusionista check that build for new spawn limit break:
OpenBOR v3.0 Build 4331
http://www.mediafire.com/file/2bkincuhm1mqq1t/OpenBOR_v3.0_Build_4331.rar
 
magggas said:
Okay, one last try to make you realize that there is something wrong with your code, and help you to where you have to look:

All it takes to reproduce the "enemy fliping bug" is just to give your enemies a "GET animation". then you will see it in person.

Why does that happen? I bet this is causing the problem:
-added new animations: "backrun"
to active it set facing {flag} and then
set the new ANIM BACKRUN
using back,back or forward,forward (in opposite direction) you'll enter in backrun
-added "facing" in entityproperty
Click to expand...
Click to expand...

eheheh not so easy! (answer is  no)

BTW found and solved!
The flip issue is caused by a bad code in openbor engine to generate a non-deterministic rand number. fixed.
The camera issue is caused by a not robust code (of your mod), where you use the variable frame (animationscript) to store a long-term value.
when I did the upgrade animscript I tried not to use the pre declared variables.
Use a personal var for a custom use. example frm = getlocalvar("frame"); like me.
As you can see are not bugs but if you want to improve things of the engine, sometimes you will have to change the mod code.
Sooner or later, if the code is not strong, you will have to improve the code.
For example, I took a look at the code of climbable ladders.
It presents some issues and limits as position where one is forced to have a pixel forward from the wall in the climbing point.
However for now all is fixed!

the engine is subject to many changes. hopefully improvements.
I had to change my game code (ladders/stairs) does not know how many times when utunnels brought improvements to the gravity vars,
until reaching a stable and robust version.

OpenBOR v3.0 Build 4332
https://sourceforge.net/projects/openbor/files/OpenBOR_v3.0_Build_4332.rar/download
 
O'Ilusionista check that build for new spawn limit break:
Click to expand...
Tried and it works! Now we can spawn entities using script in waiting anim  while in select screen.
This can help us to make easier animated select screens.

I still can't spawn it from updated.c, which could be awesome too.
 
O Ilusionista said:
O'Ilusionista check that build for new spawn limit break:
Click to expand...
Tried and it works! Now we can spawn entities using script in waiting anim  while in select screen.
This can help us to make easier animated select screens.

I still can't spawn it from updated.c, which could be awesome too.
Click to expand...

tested and working in updated.c.
using openborvariant("in_select_screen").
check coords and loadmodel() maybe is that the issue

I tried on mod (tmnt 8-bit) because my mod use custom screen.
If you need, send pm with you scripted mod.
 
Its what I am doing:

Code: 
		if(openborvariant("in_selectscreen"))
	{	
  
		void contadors = getlocalvar("contadors"); 
		void vSpawn;
		int SFX1 = loadsample("data/sounds/voices/choose.wav");
		loadmodel("teste");
		while(contadors!=1)
		{
	        playsample(SFX1, 0, 120, 120, 100, 0);
			contadors = setlocalvar("contadors",1);
			playgif("data/scenes/selectani.gif" , 0, 0, 1);
			clearspawnentry();
			setspawnentry("name", "teste");
			vSpawn = spawn();
			changeentityproperty(vSpawn, "position", 10, 20, 20);
		    return vSpawn;
			}
	}
 
magggas said:
Hey DC, download is not replaced with revision 4333. Is still revision 4321
Click to expand...

I hate being stupid, lol. I actually need to make another quick correction anyway... be up in a moment.

DC

*Edit:* Got it!
 
I tried the version 4334.
There is no flickering anymore, even with many sprites at screen. I got 1128 sprites on a scene (I bet I can get more):
6MnnVPs.png


Take a look at the picture - we got 307 sprites
Kj0jrMa.png


But once War Machine punches, the count goes to 309
eFxSu3F.png

And revert to 307 once the attack ends.

Wasn't the sprites already on the memory? I am not making the engine to draw more sprites, but to change the sprites it draws.
How the sprite count works exactly?
 
The sprite count, and maximum sprite count don't have anything to do with sprites loaded (which has no hard coded limit).

The count is instead for sprites currently displayed on the screen, which aren't just entities, but text font too. Every letter on the screen is a sprite. That's why the position debug option uses so many.

There is a hard code limit because even in the original BOR it's possible for authors to accidentally loop in more and more stuff on the screen until the hardware runs out of resources, which would of course cause a very ungraceful crash. Nothing bad happens if you reach the hard code limit - the engine simply ignores more requests for sprite display until there's room again. The effect you get on screen is flickering.

As of 4334, the limit is 5000, and again, it's only for sprites being currently displayed. That's why you'll see the count constantly going up and down.

DC
 
magggas said:
Here again with a new discovery. I found something weird but i'm not sure if is this now supposed to happen or it's a bug. So now the enemies are ingnoring the holes and they fall in. Before they where somehow blocked and could not fall in the holes by them self. Now they commit suicide all time.  ;D
Funny to watch but still weird.
This is started from Build_4320 and still happens on Build_4334 too.
Click to expand...

mmm..
from platform is normal...
btw in which level?
I tested you stage 5a but all it's. no enemies in holes.
 
Status
Not open for further replies.
Back
Top Bottom