Darren New wrote:
> Invisible wrote:
>> If you're got to actually change function prototypes then, yeah, 
>> that's not going to happen...
> 
> Not sure why not. It's actually pretty easy.
> 
> You fix the routine that needs the new parameter, and the routine that 
> has the new parameter. You compile the code. Anyone who calls the new 
> routine won't compile. Fix them to accept a new parameter and pass it 
> in. Iterate until all functions on the call chain between where you have 
> the parameter and where you need the parameter are passing it down.
> 

Aren't Callback functions often used in places where it's not easy to 
just change one thing and recompile?  I would think that many parts of 
the codebase would depend on that specific function signature being the 
way it is.

...Chambers

Post a reply to this message

Chambers wrote:
> Aren't Callback functions often used in places where it's not easy to 
> just change one thing and recompile?  I would think that many parts of 
> the codebase would depend on that specific function signature being the 
> way it is.

I would think if you have a callback routine that actually uses the third 
parameter, passing the right thing would be necessary each time, but you'd 
also have that information each time. I.e., you wouldn't be invoking the 
callback that depended on which controller was invoking it if it wasn't 
actually coming from the controller. Since the other routines didn't use 
that third parameter, they could get a dummy value there everywhere they're 
called from a context where the new parameter doesn't make sense.

I can see situations where that would be difficult to resolve, but you 
wouldn't be able to resolve it by passing the integer in cast to void* in 
those cases either.  I.e., given that they solved the problem by sometimes 
(i.e., conditionally) passing the value as the wrong type and then 
extracting it where appropriate, it doesn't seem like it's the sort of 
problem that would be hard to solve by adding a new variable of the right 
type (modulo performance problems and/or lacking some source code, of course).

If they were using a language where functions can have default arguments, 
this would the canonical example of "a good place to use that." :-)

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

> The bit I like best is where they count the number of bytes they received 
> before they turned off the receiver and then adjust the wake-up time they 
> program into the hardware, on the basis that the heat from running the 
> receiver will have made the crystal run at a different speed for the next 
> 1.28 seconds they're asleep, and you don't want to wake up too soon or too 
> late. :-)  Scary stuff going on inside there.

I know, I used to work supplying the displays for phones, and every last 
tiny bit of power reduction was always demanded.  For standby mode (when you 
haven't touched any keys for a minute or so) we ended up with reducing the 
display to just a few horizontal lines (enough to show the time and a few 
icons), reducing to 3-bit colour (ie each RGB sub-pixel either fully on or 
off) and reducing to 5 Hz refresh.  Then you can design the power supply and 
driving circuits in a clever way so that in standby you only need a fraction 
of the electronics running.  Because production volumes are so high there is 
plenty of cash around for developing really clever and complex stuff to save 
power and improve performance.

> I also found out that while my car has a bluetooth headset feature built 
> in that lets me make hands-free calls from the car without taking the 
> phone out of my pocket, lots of cars in Europe use the "SIM profile" of 
> bluetooth. So there's an entire phone built into the car that just 
> wirelessly accesses the SIM chip, pulling in the phone book of whoever is 
> in the car and everything. Very cool.

Oh yes, my current car and my last car had that.  It means when someone 
calls you the car can display the name of the person from the phonebook. 
Note that the phonebook in most phones is stored in the phone and not on the 
SIM card, because the SIM card has very limited storage capacity.  Also it 
means if you want to call someone you can scroll through the address book on 
the car display and not have to use the tiny buttons and screen on your 
phone whilst driving.

Post a reply to this message

> That's one reason why in-house tools tend to be so crappy: It's more 
> economic to accept the loss of productivity of the few people who 
> actually use it, than investing that productivity into improving it.

Exactly the reason why most level editors for games are crap.

Post a reply to this message

>> That's one reason why in-house tools tend to be so crappy: It's more 
>> economic to accept the loss of productivity of the few people who 
>> actually use it, than investing that productivity into improving it.
> 
> Exactly the reason why most level editors for games are crap.

I was wondering about that...

Personally, after using a few level editors, I find it absolutely 
*astonishing* that games are ever produced. I mean, if it takes 4 hours 
of hassle to construct an empty cuboid room, how the hell do people 
construct anything customers would pay money for?!

Post a reply to this message

Invisible wrote:
> Personally, after using a few level editors, I find it absolutely 
> *astonishing* that games are ever produced. I mean, if it takes 4 hours 
> of hassle to construct an empty cuboid room, how the hell do people 
> construct anything customers would pay money for?!

They go the UT3 route, and build the whole level in 3DS Max (you have no 
idea how much this "design decision" pissed me off when I found out. 
What's the point of UnrealEd if it just imports static meshes from Max?)

...Chambers

Post a reply to this message

>> Personally, after using a few level editors, I find it absolutely 
>> *astonishing* that games are ever produced. I mean, if it takes 4 
>> hours of hassle to construct an empty cuboid room, how the hell do 
>> people construct anything customers would pay money for?!
> 
> They go the UT3 route, and build the whole level in 3DS Max (you have no 
> idea how much this "design decision" pissed me off when I found out. 
> What's the point of UnrealEd if it just imports static meshes from Max?)

<Insert comment here about 3DS Max being even harder to operate than QOOLE>

Post a reply to this message

scott wrote:
> Oh yes, my current car and my last car had that.  It means when someone 
> calls you the car can display the name of the person from the phonebook. 

I have that too, but that's because I bluetoothed the contact list from the 
phone to the car. They slowly drift out of sync, of course, and it doesn't 
work for anyone else's phone.

> Note that the phonebook in most phones is stored in the phone and not on 
> the SIM card, because the SIM card has very limited storage capacity.  

Actually, I believe it's because the SIM card is very slow, so the phone 
caches the values when you put the SIM in.  I was under the impression the 
SIM cards stored everything of interest about your phone. I could be wrong.

> Also it means if you want to call someone you can scroll through the 
> address book on the car display and not have to use the tiny buttons and 
> screen on your phone whilst driving.

Yes, but for me that's because I copied the phone book into the car, not 
because the car is getting it from my phone real-time. It also means the car 
is using the radio in my pocket, running off tiny batteries, rather than the 
radio in the car running off a 20-pound lump of lead and acid.

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

> I have that too, but that's because I bluetoothed the contact list from 
> the phone to the car. They slowly drift out of sync, of course, and it 
> doesn't work for anyone else's phone.

Oh ok, mine must work differently then, there is no way to manually add or 
remove contacts from the car, it just displays what is in the phone.  Not 
sure at what point it grabs the data, I haven't played about with adding 
contacts while it's connected to the car.

Also lots of new cars have an "SOS" button (usually up by the rear view 
mirror somewhere) that uses a built-in phone and SIM card to call the 
emergency services.  Some cars even call this automatically within a certain 
time of an accident if you don't manually cancel it.

> Actually, I believe it's because the SIM card is very slow, so the phone 
> caches the values when you put the SIM in.  I was under the impression the 
> SIM cards stored everything of interest about your phone. I could be 
> wrong.

My SIM card apparently can only hold 100 entries, and the entries are only 
just 1 name and 1 number.  In my phone I can store multiple numbers and 
other details (eg email, address, notes etc) for each person, plus the only 
limit is the size of memory in the phone.

> It also means the car is using the radio in my pocket, running off tiny 
> batteries, rather than the radio in the car running off a 20-pound lump of 
> lead and acid.

Or an engine generating 0.1 MW :-)  Interesting point though, I don't know 
on mine whether it's the car or the phone that is actually doing the radio 
comms, I never thought that it might be the car...  I wonder how I can tell?

Post a reply to this message

scott wrote:
> 
> Or an engine generating 0.1 MW :-)  Interesting point though, I don't
> know on mine whether it's the car or the phone that is actually doing
> the radio comms, I never thought that it might be the car...  I wonder
> how I can tell?
> 

Talk a really long phone call and check how much battery your phone has
used. If less than with similar call without connected to the car, it's
pretty sure that the car is doing the radio comms.

-Aero

Post a reply to this message