Krohm

I don't really know where to look to fix this. Perhaps I should set a higher verbosity level?

So I checked project settings... they seem compatible. But maybe I've missed something. I guess so.

Or maybe I'm compiling against the wrong runtime in different packages? It seems not...

 

Ok, first thing first. While in the process of a bug hunt I have (I admit it has been a terrible idea) integrated AssImp in VC2012 build toolchain. Now I cannot get a correct executable. It compiles and it runs up to a certain point but then runs utterly amok.

Sometimes it seems to work with a full rebuild, but more often than not, it doesn't.

 

Problem is as follows. In the AssImp package,

 AssImp_ok.png   30.13K   47 downloads

So my understanding is the following. Structure dstMesh begins at SOME_ADDRESS. The pointer mFaces is stored at SOME_ADDRESS+124.

AssImp works as intended. The shaded lines of code were added by me.

The size of an aiMesh structure is 1176 bytes.

Seems legit.

 

Now let's get to my code. So there could be anything going on as it's a different project.

 Filter_wrong.png   21.67K   45 downloads

So sure I have messed up packing settings somehow.

I'm not even sure I've looked at them correctly. Perhaps I should look for pragmas.

Pointer size appears coherent.

I'm thinking about dumping offsets for all sub-fields and check the first difference in the hope to gain some insight on what's going on. I thought it might be a pointer-size difference but it's both 4 bytes.

 

Sure it's a project setting to double check. Or a defined macro? Where would you look?

While in the process of fixing a bug with my system, I stumbled in an apparent limitation, albeit I'm not sure this limitation is real.

I cannot quite figure out whatever this problem is real or not so I figured out I'd probably ask you all.

 

Situation is as follows: my mesh format exports both a graphical mesh and a physics mesh. That is, each mesh resource exports a graphics and a physics mesh.

Each time the mesh is instantiated, if the instance is marked solid, a corresponding rigid body is spawned at graphical mesh location using the mesh exported physics model.

The transform used for the physics mesh is the same as the graphical mesh.

 

However, I am having a problem with this. It appears that under certain circumstances there might be the need to append a transform from graphical meshes to physics.

So far, this has been ignored. After all meshes are supposed to be authored "centered around the origin" and the physics mesh is assumed to match the graphics mesh.

I'm tempted to not provide this extra transform at all. I cannot quite figure out a case in which this would be needed. On the other side, I cannot really find a strong reason to not do that... besides noticing supporting this features needs some care.

 

Do I need to provide a graphics-to-physics transform? 

 

It appears to me that meshes requiring this feature would be not properly authored (at least according to my current standards). But I'm not sure. Opinions welcome.

Today, I am aiming at getting a better understanding of finalizers for GC'd memory management.
Ok, they are destructors. Instead of getting called at destruction, they get called at some time in the future. Hopefully.
1st question steams from MSDN.

Finalize Methods and Destructors
Implementing Finalize methods or destructors can have a negative impact on performance and you should avoid using them unnecessarily. Reclaiming the memory used by objects with Finalize methods requires at least two garbage collections. When the garbage collector performs a collection, it reclaims the memory for inaccessible objects without finalizers. At this time, it cannot collect the inaccessible objects that do have finalizers. Instead, it removes the entries for these objects from the finalization queue and places them in a list of objects marked as ready for finalization. Entries in this list point to the objects in the managed heap that are ready to have their finalization code called. The garbage collector calls the Finalize methods for the objects in this list and then removes the entries from the list. A future garbage collection will determine that the finalized objects are truly garbage because they are no longer pointed to by entries in the list of objects marked as ready for finalization. In this future garbage collection, the objects' memory is actually reclaimed.

So perhaps the finalizer is managed as being accessed by a delegate. 1st GC pass sets an object's delegate to null and adds an entry for finalization. The object is not collected but their finalize methods are run. 2nd GC pass sees those objects as not having a finalizer to run and can therefore free their memory blob with no hassle.
Or perhaps we have sets with allocation IDs to ignore. I don't find this very important.

But why to require 2 passes? Cannot we just run the finalizer immediately before releasing a blob?
Perhaps this is consequence of having separated trace phases and a collection phases? Or maybe it's something dealing with multiple threads?

2nd question. To extend an object's lifetime, use GC.KeepAlive. I don't understand why this is needed.
[source lang="csharp"][font=courier new,courier,monospace]MyWin32.HandlerRoutine hr = new MyWin32.HandlerRoutine(Handler); MyWin32.SetConsoleCtrlHandler(hr, true);[/font][font=courier new,courier,monospace] // Give the user some time to raise a few events. Console.WriteLine("Waiting 30 seconds for console ctrl events...");[/font][font=courier new,courier,monospace] // The object hr is not referred to again. // The garbage collector can detect that the object has no // more managed references and might clean it up here while // the unmanaged SetConsoleCtrlHandler method is still using it.    // Force a garbage collection to demonstrate how the hr // object will be handled. GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); Thread.Sleep(30000);[/font][font=courier new,courier,monospace] // Display a message to the console when the unmanaged method // has finished its work. Console.WriteLine("Finished!");[/font][font=courier new,courier,monospace] // Call GC.KeepAlive(hr) at this point to maintain a reference to hr. // This will prevent the garbage collector from collecting the // object during the execution of the SetConsoleCtrlHandler method. GC.KeepAlive(hr);  [/font] [/source]
It would appear to me a better way to deal with this problem would be to have explicit notion of what SetConsoleCtrlHandler does. But I see this might not be possible. In my head, hr would not be collected anyway as there's a reference to it on the stack.
But C# GC is smarter than that... it appears it will look ahead in code to see if something is not referenced anymore and thus clean it... perhaps C# stack/start set building does not work as I expect.
Anyone knows how KeepAlive helps with the problem? I'm inclined to speculate it might actually be NOP just to prevent the flow analyzer from marking the reference unused.

Spiritual successor of this thread.
Yesterday, I received a mail from MS regarding the Win8 ugrade path. You probably don't recall that I was very positive about that.
It was so ridiculous I even checked for some spoofing. I'm currently inclined to think this is genuine. I knew my country was considered a 2nd class citizen but this is beyond lame. So I checked the english version.

Buy a Windows 7 PC and get Windows 8 Pro for £14.99
The offer is for customers (e.g. Home users, students, and enthusiasts) who purchase a qualified PC. A qualified PC is a new PC purchased during the promotional period with a valid Windows 7 OEM Certificate of Authenticity and product key for, and preinstalled with:
Windows 7 Home Basic;
Windows 7 Home Premium;
Windows 7 Professional; or
Windows 7 Ultimate.
...
Each upgrade license will apply to only one PC and may only be installed on PCs with a valid base license to a qualifying operating system (i.e., Windows XP SP3, Windows Vista or Windows 7).

But... I found no instructions on how to deal with Vista and 7. I'm tempted to just try buying to see if it works but I guess I won't do that.
This is fail.

Note: today topic tags are broken for me: they will lock on "wi" "ndow" "s".

A friend of mine asked me if I could write him a small proggie for a stupid thing he needed. Didn't look harder than a few days of work and I had previous experience with both AWT and Swing so why not?
I asked another friend of mine for some additional pointers ... I wish I listened. Instead, I also looked at the official Java docs where I was informed of this new JavaFX thing which is good and awesome and The Only Real Thing You Need To Create SlickInterfaces.
Ok so I give it a go. Being the successor to Swing it must be at least just as good I suppose!
Not really. I think I haven't tasted this kind of pain in quite a while.
Perhaps I'm asking the impossible but... it seems to me those dudes are expecting us to just load & display images. No processing. Not even a way to pull out the pixels... unless you use previous components (goodbye to "the only thing you need" part of the joke). Maybe I'm asking too much?
Maybe that's just me but I think the API is just flat out broken. Or perhaps I'm messed up in the head... because it looks to me for rich sleek UIs like C.S.I. we would need at least a way to get our hands dirty with pixel juggling.
And I cannot quite get the emphasis on certain features. Look, you got a whopping 15 different widgets out of the box! And none includes a file selector, nor a color picker! Or perhaps I have just missed the whole point after two days going in circles on the docs? What the hell.

I'm now torn between

• Tell him to bite the bullet himself
• Go back to swing
• Bite the bullet and go C# (goodbye to portability, but I'm fairly sure it won't be as retarded as the Java environment)!

Suggestions/Opinions?