LavaLit
  Home   Forum   WIKI SVN DOWNLOADS Help Donations Login Register  
* *

Donations

Quarterly Goal: $90.00
Due Date: Sep 30
Total Receipts: $10.00
Below Goal: $80.00
Site Currency: USD
 11%
Quarterly Donations
Jul-18 mozenwrath... EUR10.00
Jul-1 LeeBrother USD10.00
Advertisement

Links

Advertisement
Pages: 1 ... 12 13 [14] 15   Go Down
  Print  
Author Topic: OpenBoR v3.0 Build 2123  (Read 15513 times)
0 Members and 1 Guest are viewing this topic.
BonusJZ
Hero Member
*****
Offline Offline

Posts: 1091


Banned


WWW
« Reply #195 on: March 19, 2009, 10:28:48 AM »

Quote
I wanted to get this build out so I can get feedback.  I wanted to make sure I didn't break anything or introduce any new bugs with all these optimizations.  Feedback would be great on this build.  Thanks in advance!!

So far everything work good - except bosslow.

First default (old level.txt boss (bi}) slowmotion on boss death don't finish as previous and will be really nice if that can be put-ed back (for backward compability / etc)

I have also try-ed scripted version of slow and have a little problems with setting duration (it works when turn on but I need manually turn it off) . But let someone confirm this please.

As for memory - well there still big problem with animation limit even on PC :

OpenBoR v3.0 Build 2167, Compile Date: Mar 18 2009

********** An Error Occurred **********
*            Shutting Down            *

Total Ram: 1535377408 Bytes
Free  Ram: 1505095680 Bytes
Used  Ram: 30289920 Bytes

Release level data...........   Done!
Release graphics data........   Done!
Release game data............   Done!
Release timer................   Done!
Release input hardware.......   Done!
Release sound system.........   Done!

**************** Done *****************

Not enough memory for animations!List_InsertAfter: 5364 bytes in 447 allocs
Instruction_InitViaToken: 57572 bytes in 389 allocs
Parser_AddInstructionViaToken: 15560 bytes in 389 allocs
NAME(s): 327 bytes in 78 allocs
Instruction_InitViaLabel#2: 8256 bytes in 64 allocs
Instruction_InitViaLabel#1: 9472 bytes in 64 allocs
Parser_AddInstructionViaLabel: 2320 bytes in 58 allocs
List_InsertBefore: 84 bytes in 7 allocs
Parser_Param_list2: 240 bytes in 6 allocs
StackedSymbolTable_PushScope: 160 bytes in 1 allocs
Script_Init#2: 1596 bytes in 1 allocs
font_load: 33540 bytes in 256 allocs
Total Leaked Bytes 134491

Quote
I'm still a few MBytes shy of loading your test mod BonusJZ on my PSP.  Seems I still need a few more optimizations.  But I would like to make sure I didn't break anything as of yet in the process.

So far so good  - just keep in mind its use scripts to "virtually" rise memory use and there can be a problem with animations (when the scripts are optimized)
« Last Edit: March 19, 2009, 10:40:42 AM by BonusJZ » Logged

SX
Administrator
*****
Offline Offline

Posts: 2461



WWW
« Reply #196 on: March 19, 2009, 11:35:25 AM »

So far everything work good - except bosslow.

First default (old level.txt boss (bi}) slowmotion on boss death don't finish as previous and will be really nice if that can be put-ed back (for backward compability / etc)

Not sure I understand what you are trying to say?  Do you mean if you use "boss -1" it does not end the level?
Logged

BonusJZ
Hero Member
*****
Offline Offline

Posts: 1091


Banned


WWW
« Reply #197 on: March 19, 2009, 11:46:59 AM »

Its ok - its ending the level even with multiple bosses and the bug on final boss hit is gone  cheers!

But the normal command boss 1 in level.txt not work as previous (before was lasting only lets say 2 second now its lasting till last frame of death and if last frame is long ... well its not good  Sad)

example:
boss first fall , trying get up from ground , then finally playing its death pose .... slow effect its way to long and destroys dramatics
(not to mention about extra empty delay frames for nice level fade out effect or character victory pose)

If its possible to have bosslow from command as before along with one controlled with script - I think that will be best solution


« Last Edit: March 19, 2009, 11:57:00 AM by BonusJZ » Logged

BurnKing
Hero Member
*****
Offline Offline

Posts: 898



« Reply #198 on: March 19, 2009, 01:39:21 PM »

sorry to interject but i set this up on my comp and it said couldnt find msvcr71.dll where do i find this?
Logged

Fight Night Champ

Mods: BurnKingdom Chapter One
         Marvel Super Heroes
         Guardian Heroes: WarPath

WIP:   Irish Gangster
          BurnKingdom Chapter Two
Bloodbane
Hero Member
*****
Online Online

Posts: 4727


Dark Dragon


« Reply #199 on: March 19, 2009, 02:35:43 PM »

 I have to interrupt too. I got several questions related to new features:

1. Do 'guardpoints', GUARDBREAK and 'guardcost' only affect blocking with BLOCK animation or any custom block animations? including animations with autoguard.

2. When entity plays GUARDBREAK, was previous attack blocked or received?

3. For those who don't know, we can access options menu by pressing 'screenshot' while pausing the game. Now, if 'noscreenshot 1' is set, can we still access menu by that method?
Logged

OpenBoR Manual

"The more often enemies attack, the more open they are to counter attacks"
BonusJZ
Hero Member
*****
Offline Offline

Posts: 1091


Banned


WWW
« Reply #200 on: March 19, 2009, 02:38:41 PM »

As for 3 - yes you still can access it Sad

Quote
sorry to interject but i set this up on my comp and it said couldnt find msvcr71.dll where do i find this?


http://lmgtfy.com/?q=msvcr71.dll+
« Last Edit: March 19, 2009, 03:08:00 PM by BonusJZ » Logged

Damon Caskey
Administrator
*****
Offline Offline

Posts: 4294



WWW
« Reply #201 on: March 19, 2009, 02:49:11 PM »

1. Do 'guardpoints', GUARDBREAK and 'guardcost' only affect blocking with BLOCK animation or any custom block animations? including animations with autoguard.
When you script the block flag for autoguard, it uses the same block system (The BLOCKPAIN animation is skipped though). So most likely, other "block" moves ARE affect by the guard point system. You'll need to test to make sure.

Quote
2. When entity plays GUARDBREAK, was previous attack blocked or received?

The attack that puts defender into GUARDBREAK is treated as if it were blocked. The idea is that defender still blocks the hit, but is then wide open for any subsequent hits while in GUARDBREAK animation. You are of course free to think outside the box and make GUARDBREAK do whatever.

DC
Logged

OpenBOR Wiki.

Coming Soon:
Fatal Fury Chronicals

SX
Administrator
*****
Offline Offline

Posts: 2461



WWW
« Reply #202 on: March 19, 2009, 03:14:00 PM »

The Animation memory issues you found is due to the fact you are using over 2000 animations!!  So its not a bug.... its just you have gone over the limit.  So do we need a new limit?  For the most part the memory usage per animation has been greatly reduced and there are no more optimizations left to be done.

So increasing the size should from 2000 to 3000 should only take up ~150 KBytes of Memory if not used (Reserving initial space for new animations).  Hence, if you were only using 2000 Animations before memory will increase ~150 KBytes.  If you use 3000 Animations then memory will sky rocket depending on the options you enable for that frame, since things are dynamically allocated on the fly.
Logged

Orochi_X
Administrator
*****
Offline Offline

Posts: 3062


Now! Count up your crimes.


« Reply #203 on: March 19, 2009, 03:20:04 PM »

Yeah. DC , myself and some others are flirting dangerously close to the limit at the moment....

A slight bump up wouldn't hurt   Smiley
Logged



* Orochi_X says : " Sore ga doushita? " looney
BonusJZ
Hero Member
*****
Offline Offline

Posts: 1091


Banned


WWW
« Reply #204 on: March 19, 2009, 03:22:45 PM »

Quote
The Animation memory issues you found is due to the fact you are using over 2000 animations!!  

Well that after 3 stage - where entities from rest 5 stages.....

Quote
So increasing the size should from 2000 to 3000 should only take up ~150 KBytes of Memory if not used (Reserving initial space for new animations).

Maybe better to 4000 ..... just counted only frames from chars folder and its 3484
« Last Edit: March 19, 2009, 03:25:17 PM by BonusJZ » Logged

BurnKing
Hero Member
*****
Offline Offline

Posts: 898



« Reply #205 on: March 19, 2009, 08:28:42 PM »

Quote from: BonusJZ link=topic=2502.msg36369#msg36369
[url=http://lmgtfy.com/?q=msvcr71.dll+


that was the best thing ive seen all day, sorry i assumed i was missing something from the package maybe shud have thought it through
Logged

Fight Night Champ

Mods: BurnKingdom Chapter One
         Marvel Super Heroes
         Guardian Heroes: WarPath

WIP:   Irish Gangster
          BurnKingdom Chapter Two
SX
Administrator
*****
Offline Offline

Posts: 2461



WWW
« Reply #206 on: March 19, 2009, 11:35:37 PM »

Instead of increasing the animation limit.  I will look into creating a link list and map tables.  This might be a better solution for memory.  This way we only alocate memory for this structure when needed.  This will theortically remove any imposed limit.  Just any idea...
Logged

MCW
Hero Member
*****
Offline Offline

Posts: 1068


BOR = Beats Of Rage


« Reply #207 on: March 20, 2009, 08:00:40 AM »

The slow motion effect and kill all enemies does not work while 2pspawn/3pspawn/4pspawn is used for the boss.

EDIT
This is because the boss does not spawn completely if only player 1 is in the game.

The makeinv is not function and cause the parrow# does not display. The riseinv is also not function.

« Last Edit: March 20, 2009, 08:28:43 AM by MCW » Logged



Be a Good Reader,
Read the post from first word until to the last.
BonusJZ
Hero Member
*****
Offline Offline

Posts: 1091


Banned


WWW
« Reply #208 on: March 20, 2009, 09:52:28 AM »

Quote
The slow motion effect and kill all enemies does not work while 2pspawn/3pspawn/4pspawn is used for the boss.

Just tryed - confirm

Quote
The makeinv is not function and cause the parrow# does not display. The riseinv is also not function.

Its display but only for a second , character not blinking (regardless of makeinv setting)

Also you need to be more strict with scripts occurring in fall (now you need to pointed to proper fall number).

Quote
Instead of increasing the animation limit.  I will look into creating a link list and map tables.  This might be a better solution for memory.  This way we only alocate memory for this structure when needed.  This will theortically remove any imposed limit.  Just any idea...

If this might help its worth a try - do you magic SX cheers!
« Last Edit: March 20, 2009, 10:31:00 AM by BonusJZ » Logged

Orochi_X
Administrator
*****
Offline Offline

Posts: 3062


Now! Count up your crimes.


« Reply #209 on: March 20, 2009, 10:22:56 AM »

Quote
Also you need to be more strict with scripts occurring in fall (now you need to pointed to proper fall number).

What do you mean by this?

On a side note , if you want the script to run on all fall animations , it would be quicker to check for the falling aiflag instead of the animations.
Logged



* Orochi_X says : " Sore ga doushita? " looney
Pages: 1 ... 12 13 [14] 15   Go Up
  Print  
 
Jump to:  

Advertisement

Recent Topics

[July 31, 2010, 02:11:35 AM]

[July 31, 2010, 02:05:43 AM]

[July 31, 2010, 01:52:02 AM]

[July 31, 2010, 01:40:20 AM]

[July 31, 2010, 12:56:09 AM]

[July 31, 2010, 12:41:56 AM]

[July 31, 2010, 12:36:44 AM]

[July 31, 2010, 12:30:45 AM]

[July 31, 2010, 12:27:09 AM]

[July 31, 2010, 12:14:08 AM]

Online Status

Members
Stats
  • Total Posts: 67003
  • Total Topics: 4515
  • Online Today: 33
  • Online Ever: 117
  • (October 23, 2009, 03:29:26 PM)
Users Online
Users: 6
Guests: 23
Total: 29
TinyPortal v1.0 beta 4 © Bloc
Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC
Valid XHTML 1.0! Valid CSS!
Page created in 0.288 seconds with 40 queries.

Google visited last this page July 13, 2010, 01:38:09 PM