Problem: BM1.26 and DX9-Module

BlitzMax Forums/BlitzMax Programming/Problem: BM1.26 and DX9-Module

Derron(Posted 2007) [#1]
Like stated some weeks ago it's not possible to use the DX9-Module with BM1.26.

Although the source is able to compile it crashes with conflicts within the reflection-stuff of BM.

Did someone found a way to circumvent it?

---
Function TypeIdForTag:TTypeId( ty$ )
....
For Local i=0 Until ar
--->here> id=id.ArrayType()
Next
---

I think the reflection module gets the exception because of an unknown 'type' within the DX9-module.


Hope this time some people (or minimum one ;D) may help me (and surely some others).


bye
MB


dmaz(Posted 2007) [#2]
I'm using Doug Stastny's dx9 includes without problems...


Derron(Posted 2007) [#3]
With BM1.26?

Getting Reflection-Errors with it...

like the function quoted above (laying in brl/reflection-module).


Do you use Strict-Mode or "feel free to interpret my variables"-mode?


bye
MB


dmaz(Posted 2007) [#4]
yeah, I might have modified it, I'll check when I get home ( 5hr)


DStastny(Posted 2007) [#5]
Uncheck quick build and compile, that is probably the cause of your problems.


dmaz(Posted 2007) [#6]
yeah... it doesn't look like I made any code changes... but I did have an initial problem that you are seeing. try what budman suggests... also I know I compiled Dx9Max2dGraphicsDriver.bmx by itself and then I just import it.


Derron(Posted 2007) [#7]
I'm using BMax for some years now ... so please imagine I tried without "quick build" enabled... it compiles fine but after loading my images I get a memory exception within the reflection module.

--- Ok, tried a bit... disabled reflection-cloning (seems they have trouble with TObjectList (code out of the code archives).

Now I have to go through the code to make it work with TRender (by indiepath I think) and DrawImageArea (modified by Grey Alien).
In the DX9-Module things like 'CreateSurface' are missing and I'll have to checkout what to do to make it working.


bye
MB


Derron(Posted 2007) [#8]
Ok ... after disabling some functions to test it (to circumvent the tobjectlist) the next problem was the
drawImageArea-function... no big issue to make it work.

The RenderToTexture-Thingy by indiepath made my brains cook in their own soup.
I managed it to create surfaces and so on ... then when no more errors directly occoured the next thing making the debugger throwing something were all DrawText-commands ... and so on ...

So each problem I thought to have solved was chained to another, new, problem. The conclusion is : my changes to the RTT-code were not the correct/needed ones.


Someone having RTT with DX9 running and willed to share the source?


bye
MB


Derron(Posted 2007) [#9]
Hmm ... disabled/converted all TObjectList-Types to normal TList and it still crashes when using DX9.

It crashes when evaluating my individual types... calling for example:

	Method CloneProgramme:TProgramme(_Programme:TProgramme) 
		Local typ:TTypeId = TTypeId.ForObject(TProgramme(_Programme)) 
		Local clone:TProgramme = New TProgramme
		For Local t:TField = EachIn typ.EnumFields() 
			t.Set(clone, t.Get(_Programme)) 
		Next
		TProgramme(clone).clone = 1
		ProgList.AddLast(clone) 
		Return clone
   End Method


Makes it crashing on:
'local typ:TTypeId = TTypeId.ForObject(_Programme)'
(with or without strictly casting it to TProgramme makes no difference).

Same goes for all "clone functions" i wrote within this application ... Disabling the first, makes it crash on the second and so on.

Some ideas?


bye
MB


dmaz(Posted 2007) [#10]
I know you don't have to do all of that..
try this, it's already compiles so just do
Import "dx9tests\Dx9Max2dDriver\Dx9Max2dGraphicsDriver.bmx"

http://www.ooeyug.com/files/dx9tests.rar

is that code different than what you have?


Derron(Posted 2007) [#11]
Did a full recompile (no quick-mode) and still no changes...still crashing with memory exception.

The code is the same like the one I use.

bye
MB


DStastny(Posted 2007) [#12]
Michael,

I dont think the problem is with the Dx9 import(its not a module) as it doesnt do anything fancy in regards to manipulations in Max its pretty straight forward code. Now there seems to be some references to you to other code such as RTT and TObjectLists.

So lets examine your problem from that perepsectve. Does the sample program that I provided in the archive compile and run? If you are mixing the RTT code by Inidiepath did you actually translate all the dx7 portions of his code to dx9? I am more than sure you can make it compile unmodified but its not going to work as it has no clue about the dx9 code. Things like createsurface you re referencing are specific to the dx7 implmentation.

My Dx9 Driver implments BlitzMax Graphics commands it does not attempt to mimic DirectX7 or the Directx7 implmentation although some areas as far as windows managment etc are simliar due to nature of the Graphics architecture in Max.

I will be more than willing to help you debug issues with the Directx9 driver. I wont however debug other peoples customizations to it. It is designed to provide a Dx9 Max2d driver for hardware that supports dx9.

If you can post a simple sample that does not compile that just imports the dx9 driver, post it and I will reload BlitzMax and update it to 1.26 and take a look at it.

Take a step back with your program. Just write the simplest thing then start adding what you think might be cause of problem. I am pretty sure its not the driver, but there might be something....

Doug Stastny


Derron(Posted 2007) [#13]
OK... smallest thing crashing reflection using the dx9-'module'.

1) open the file Dx9Test.bmx (from your hdd or from the attachment of dmaz' posting)
2) add to 'Type TParticle'
	Method Clone:TParticle() 
		Local typ:TTypeId = TTypeId.ForObject(Self) 
		Local clone:TParticle = TParticle.Create()
		For Local t:TField = EachIn typ.EnumFields() 
			t.Set(clone, t.Get(Self)) 
		Next
		Return clone
   End Method


3) in 'Function CreateFirework(Image:TImage, posX:Float, posY:Float)' add:
			sp.clone()


before the functions end:
	
		Next
	End Function



When now compiling everything will work - but when clicking the left mouse button it will throw an exception within the reflection module.

And remember - this only happens when using DX9 - OGL and DX7 work fine - so I can imagine that the calls within the clone-method and something within your (budman) code makes BMax a bit crazy ;D.


bye
MB

ps: I know that it is not the perfect example ... the cloning may crash the app AFTER the particle lifetime expires (image NULLed) ... but it crashes when accessing TTypeID.ForObject()


DStastny(Posted 2007) [#14]
@MichaelB

Thanks for example. Good news is I duplicated and found your problem.

Bad news is it looks like a bug in the reflection code. For some reason it does not seem to like arrays of Types that are of Iunknown. The Dx9 driver uses this to minimize state changes and manages this with an array of

_BlendStateBlocks: IDirect3DStateBlock9[6]

It is evaluating this that is causing the reflection to choke best I can tell with 5 minute debug.

Seems like first time you call type of it scans all the types in the program and builds a list. When processing the dx9drive it chokes on the _BlendStateBlocks in the array handling code.


I am going out with wife and kids tonight, but I'll see if I can find some time to create and example bare minumum with out directx9 to demonstrate bug to mark and hopefully he can fix.

Doug Stastny


DStastny(Posted 2007) [#15]
Here ya go here is the bug

Strict

Extern "Win32"
Type IDirect3DStateBlock9 Extends IUnknown
	Method GetDevice(ppDevice: IDirect3DDevice9 Var)
    Method Capture()
    Method Apply()

End Type
End Extern


Type TFoo
'	Field _BlendStateBlocks: IDirect3DStateBlock9[6] ' crash
	Field unk : IUnknown[6] ' crash
	'Field _BlendStateBlock: IDirect3DStateBlock9   ' no crash
End Type
  


Local foo:TFoo= New TFoo
Local typ:TTypeId = TTypeId.ForObject(foo)
Print typ.Name()


It seems Reflection does not like types derived from IUnknown when they are in an array.

Doug Stastny


Dreamora(Posted 2007) [#16]
Reflection most likely does not like to operate on non BM data (ie not managed code).
This means no pointer and no extern. Especially the later can not be reflected, they are no BM classes at all (you can not extend them as well)


DStastny(Posted 2007) [#17]
@MichealB

Mark has posted that its fixed in next update. Sorry youll have to wait.

Doug Stastny


Derron(Posted 2007) [#18]
Hmm.. Okay... we will have to see... thanks for your engagement.

So it seems I spend some useless hours full of sweat and boredom (manual refactoring to convert back to normal lists).


@dreamora: do you know a way to manually enable reflection to 'unknown code' (like added meta-tags)? Or a way (without modifying brl-code) to disable the reflection-scan on certain types ?


bye
MB


Dreamora(Posted 2007) [#19]
So far, I don't know a way, sorry Michael.
perhaps there is a noReflection tag for classes similar to the noDebug for functions (which you never want to be debug compiled like math heavy functions or loop monsters you are sure they are correct)

What do you mean with:

do you know a way to manually enable reflection to 'unknown code' (like added meta-tags)?


Do you have an example? do not really understand what you mean.


Derron(Posted 2007) [#20]
You know meta-tags and it could have been that there is a way to manually assign "base types" to certain variables to make reflection work.

--- in German for Dreamora only ---
Ich wollte wissen, ob es moeglich ist einem unbekannten Typ eine Basisklasse als Meta-Tag beizufuegen um somit die Reflection-Sache zum Laufen zu bekommen. Schaetze aber mal das geht nicht, denn wenn man wuesste welcher Typ da zu erwarten waere, koennte man ihn auch nutzen.
---

Sorry for the German words, but this way I think Dreamora will understand my post much better (both native German-speakers).

bye
MB


Dreamora(Posted 2007) [#21]
There is actually no unknown type.
Anything with reflection is extended from Object and therefor you can reflect it if you want to.

So basically you can add data (like a name or even meta tag if you want to) to your classes and to do reflection on that, use the TTypeID capabilities from a string (-> your meta data) to reflect it.

I hope this is what you meant. Missusing reflection for Java like Interfacing ;-)


Derron(Posted 2007) [#22]
I wanted to know that to bring the dx9-thing back to life when using reflection...

So not another way to get names of variables - only a way to learn reflection "my" new types/functions.


bye
MB


Dreamora(Posted 2007) [#23]
reflection must not learn anything. If the type is there it already knows the type and all of its fields, globals etc. No need to make it aware of anything.

Only exception is extern and ptr. They can not be used at the moment. This has not much to do with beeing aware or not.
Its more due to the fact that they do not extend object (extended Types can not be extended in BM!) nor are they one of the core types (numerics, string or array), at least thats my assumption for the cause of the reflection problem. So they simply never exist within the running applications actually as objects or core class.
But Mark mentioned that this is fixed, so with 1.28 it should work.


If this is still not the right thing an example of what you want to achieve and that does not work (ie a simple use case).

PS: I hope your planning does not involve using reflection on anything speed critical. That actually would cause some serious issues to your project


Derron(Posted 2007) [#24]
No the reflection is mostly needed when saving/loading takes place or when eg. a user clicks the mouse (eg. buying a movie/series in the "movies agency" (may be you know the game MadTV)). No no speed issue at all ... only readability and easy maintenance.

Hope 1.28 isn't delayed too much.


bye
MB