per player bit flag limit

21 views
Skip to first unread message

james cardona

unread,
Feb 7, 2013, 1:04:00 PM2/7/13
to fre...@googlegroups.com
I seem to recall that there was an arbitrary limit of 64 to the per player bit flags but I can't seem to find where that is set as I would like to increase it.  Any one know where that is or am I just going bonkers?

Brian Dominy

unread,
Feb 7, 2013, 1:13:46 PM2/7/13
to fre...@googlegroups.com
Look in include/freewpc.h for MAX_FLAGS.  It is set to 64 now.  It must be a multiple of 8.  It should be safe to go up to 128.

Brian

On Thu, Feb 7, 2013 at 1:04 PM, james cardona <JAMES....@pseg.com> wrote:
I seem to recall that there was an arbitrary limit of 64 to the per player bit flags but I can't seem to find where that is set as I would like to increase it.  Any one know where that is or am I just going bonkers?

--
 
---
You received this message because you are subscribed to the Google Groups "FreeWPC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to freewpc+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
- Brian

Cardona, James E.

unread,
Feb 7, 2013, 2:49:59 PM2/7/13
to fre...@googlegroups.com
thanks  - I am with 67 flags so far and code reports 26% full so def could go to 192 and perhaps 256 - I shouldn't need more than 128 though


The information contained in this e-mail, including any attachment(s), is intended solely for use by the named addressee(s). If you are not the intended recipient, or a person designated as responsible for delivering such messages to the intended recipient, you are not authorized to disclose, copy, distribute or retain this message, in whole or in part, without written authorization from PSEG. This e-mail may contain proprietary, confidential or privileged information. If you have received this message in error, please notify the sender immediately. This notice is included in all e-mail messages leaving PSEG. Thank you for your cooperation.

Brian Dominy

unread,
Feb 7, 2013, 2:57:28 PM2/7/13
to fre...@googlegroups.com
There's another limit you have to be careful of - a maximum of 48 bytes of per-player data, which includes lamps (8 bytes), flags (1 byte for every 8 flags), and other variables declared with __local__.  Going to 128 flags only added another 8 bytes, so unless you have a lot of __local__ vars, you should be OK.

I also think there's a bug in the percentage calculation, where it reports the value too small... so try not to get too close to 100%.

Brian

james cardona

unread,
Feb 11, 2013, 2:30:59 PM2/11/13
to fre...@googlegroups.com, br...@oddchange.com
Hmmm... my local page shows 85% full and flags shows 26% full - but you are saying that there is a limit that takes into account both together? 

I just counted up all my __local__ vars and I have 45 (not counting those that are extern __local__ , as I am assuming that is a pointer) with the previous bytes you mentioned I am over 48 and perhaps that is where my bug lies?
By the way, does a boolean take up a full byte on 6809?

Brian Dominy

unread,
Feb 11, 2013, 4:06:21 PM2/11/13
to fre...@googlegroups.com, Cardona, James E.
The local % shown takes both into account.  It is the size of the memory needed for locals & flags & lamps combined.  However there's a bug that the value it shows is incorrect.  In Makefile, search for AREA_SETUP and local.  The 0x0040 should be changed to 0x0030, since that's the maximum - 48 bytes total.  It should match the value LOCAL_SIZE in include/platform/wpc.h.  Once you change that, the percentage should go up, and I suspect it will actually go to over 100% indicating a problem.

The flags % is just the percentage of the maximum number of flag IDs, which is 256.  You could use the maximum 256 flags, which would take 32 bytes (since flags are packed), if you only needed a few __local__ variables.  The actual maximum number of flags is however limited to the values MAX_FLAGS, which is much less than this.  The % shown does not reflect this.  These two maximums really need to be integrated better.

extern __local__ doesn't take up any additional memory (same goes for extern anything).

If you have 45 bytes of __local__, that's definitely too much.  The 48 bytes is used for (1) __local__, (2) flags, packed 8 to a byte, and (3) 8 bytes for the lamp matrix.  You can't change the lamp matrix size, so at most you could only have 37 bytes of __local__, if you had no flags at all.

If you declare a variable of type bool, yes it takes 1 whole byte... that's the only purpose of flag_t and global_flag_t, to save space.

Brian

james cardona

unread,
Feb 12, 2013, 9:06:21 AM2/12/13
to fre...@googlegroups.com, Cardona, James E., br...@oddchange.com
This was excellent info!  Thanks! 

I just spent the last several hours trying to eliminate __local__'s without deleting features and it put me right back into the 1980's, when I first started coding mac 2e's and IBM pc's (yeah - the original ones), and we had such severe memory limits (no hard drives - all code ran off a 5 1/4 floppy).  That was kinda cool bringing back those memories -not like today where we are so reckless with creating new variables for everything. Hey by the way, I am 45 and started coding seriously when I was 11-12 years old.

Anyway, I am down to 30 __local__'s and with changes to reporting, I am at 75% so should be safe.  I have fingers crossed that this is my mystery bug and will check tonight when I get home.

Thanks again!!

james cardona

unread,
Feb 14, 2013, 11:02:20 AM2/14/13
to fre...@googlegroups.com, Cardona, James E., br...@oddchange.com
Well I recompiled and the mystery bug did not go away - but I am certain this fixed something anyway.  Will outlin my mystery bug in a nother thread and maybe someone has an idea
Reply all
Reply to author
Forward
0 new messages