locked
Any progress on the 3D extension? RRS feed

  • Question

  • Hi,

    Just wondering if there has been any progress on the 3D extension for 32 bit. I keep checking but nothing seems to have changed with it.

    Thanks

    Saturday, October 20, 2012 8:29 PM

Answers

  • I think the dll issues are solved and works on at lease one 32 bit machine.  All downloads for testing on my SkyDrive here

    If all is OK the next stages would be to consider what meshes people want to use and then some other game-play commands - I already added some collision detection and basic mouse selection events.

    Tuesday, October 23, 2012 8:12 AM

All replies

  • I was going to decompile it an take a look at it, but I realized it would be harder than I though since it contains both C# and unmanaged? C++ code --- something I am not very experienced with. Maybe Litdev could provide some more inforamation on this. I think he has an x64 machine, so he would need a 32-bit virtual machine to test this. I have done that before with my extension, the PlusPlus extension, and it was very cumbersome and I stopped providing 64 bit support after a while.

    In the end, I suggest inversting in a 64-bit computer --- maybe around $300, but worth every bit in my opinion.


    Please mark any answers and "vote as helpful" any posts that help you!



    Saturday, October 20, 2012 9:15 PM
    Answerer
  • I think he has an x64 machine, so he would need a 32-bit virtual machine to test this.


    Please mark any answers and "vote as helpful" any posts that help you!


    Processors that support x86-64 (and I believe IA64) will emulate a 32-bit environment so that programs compiled for 32-bit will still run. They also maintain hardware compatibility (i.e. a 64-bit processor will still have the 32-bit registers EAX and EBX, but a 32-bit processor will not have the 64-bit registers RAX and RBX).
    Sunday, October 21, 2012 1:31 AM
  • I think he has an x64 machine, so he would need a 32-bit virtual machine to test this.


    Please mark any answers and "vote as helpful" any posts that help you!


    Processors that support x86-64 (and I believe IA64) will emulate a 32-bit environment so that programs compiled for 32-bit will still run. They also maintain hardware compatibility (i.e. a 64-bit processor will still have the 32-bit registers EAX and EBX, but a 32-bit processor will not have the 64-bit registers RAX and RBX).
    Thanks Liam for the info, but that's not what I meant. I meant that the OS he is using is 64 bit, not the actual computer (poor word choice on my part). The thing doesn't run on a 32 bit OS. Yeah, of course the lower 32 bits of the Rxx regs will be available as Exx  but the way Windows handles things is a bit different. I am an OS developer and program in assembly sometimes, but never in x64 assembly, so I am no expert in AMD64 / IA64 architectures so I don't know exactly why it doesn't run. Maybe a test with a debugger stepping through the code concurrently on a 64 bit and a 32 bit OS with a locals windows open could shed some light on where the mess-up is going on. Does anybody want to try this?

    Please mark any answers and "vote as helpful" any posts that help you!

    Sunday, October 21, 2012 3:04 AM
    Answerer
  • I think he has an x64 machine, so he would need a 32-bit virtual machine to test this.


    Please mark any answers and "vote as helpful" any posts that help you!


    Processors that support x86-64 (and I believe IA64) will emulate a 32-bit environment so that programs compiled for 32-bit will still run. They also maintain hardware compatibility (i.e. a 64-bit processor will still have the 32-bit registers EAX and EBX, but a 32-bit processor will not have the 64-bit registers RAX and RBX).

    Thanks Liam for the info, but that's not what I meant. I meant that the OS he is using is 64 bit, not the actual computer (poor word choice on my part). The thing doesn't run on a 32 bit OS. Yeah, of course the lower 32 bits of the Rxx regs will be available as Exx  but the way Windows handles things is a bit different. I am an OS developer and program in assembly sometimes, but never in x64 assembly, so I am no expert in AMD64 / IA64 architectures so I don't know exactly why it doesn't run. Maybe a test with a debugger stepping through the code concurrently on a 64 bit and a 32 bit OS with a locals windows open could shed some light on where the mess-up is going on. Does anybody want to try this?

    Please mark any answers and "vote as helpful" any posts that help you!

    It doesn't matter if he's running a 32-bit OS or a 64-bit OS. Either way, the processor will still emulate an x86 environment, and the OS (unless it is a 16-bit OS, which it isn't) will be able to execute a 32-bit program using the x86 emulation.

    It would be a poor design decision to make it so x86 program did not work on x86-64, considering x86-64 is just an extension to x86-32, which is just an extension to the original x86. Backwards compatibility is maintained to the point where many x86-64 processors will still contain hardware that allows them to execute original x86 (16-bit) programs.

    Still don't believe a 32-bit program works in a 64-bit environment? Unless you are using Waterfox, your web browser is 32-bit. If you're using Win7, go into the task manager and see. If there's "* 32" beside its name, it's 32-bit.

    Sunday, October 21, 2012 10:07 AM
  • I think he has an x64 machine, so he would need a 32-bit virtual machine to test this.


    Please mark any answers and "vote as helpful" any posts that help you!


    Processors that support x86-64 (and I believe IA64) will emulate a 32-bit environment so that programs compiled for 32-bit will still run. They also maintain hardware compatibility (i.e. a 64-bit processor will still have the 32-bit registers EAX and EBX, but a 32-bit processor will not have the 64-bit registers RAX and RBX).

    Thanks Liam for the info, but that's not what I meant. I meant that the OS he is using is 64 bit, not the actual computer (poor word choice on my part). The thing doesn't run on a 32 bit OS. Yeah, of course the lower 32 bits of the Rxx regs will be available as Exx  but the way Windows handles things is a bit different. I am an OS developer and program in assembly sometimes, but never in x64 assembly, so I am no expert in AMD64 / IA64 architectures so I don't know exactly why it doesn't run. Maybe a test with a debugger stepping through the code concurrently on a 64 bit and a 32 bit OS with a locals windows open could shed some light on where the mess-up is going on. Does anybody want to try this?

    Please mark any answers and "vote as helpful" any posts that help you!

    It doesn't matter if he's running a 32-bit OS or a 64-bit OS. Either way, the processor will still emulate an x86 environment, and the OS (unless it is a 16-bit OS, which it isn't) will be able to execute a 32-bit program using the x86 emulation.

    It would be a poor design decision to make it so x86 program did not work on x86-64, considering x86-64 is just an extension to x86-32, which is just an extension to the original x86. Backwards compatibility is maintained to the point where many x86-64 processors will still contain hardware that allows them to execute original x86 (16-bit) programs.

    Still don't believe a 32-bit program works in a 64-bit environment? Unless you are using Waterfox, your web browser is 32-bit. If you're using Win7, go into the task manager and see. If there's "* 32" beside its name, it's 32-bit.

    I believe you Liam, and you are right. Still, some programs, like this 3D extension do not run on 32-bit OSes and that has been confirmed. The one thing I can think of is that since some of it runs in Unmanaged C++, it calls some sort of 64-bit Windows kernel function or relies on some 64 bit driver (maybe a graphics accelerator for 3D). Of course, RAX still contains EAX and AX and even AH / AL for compatability with 32, 16 and 8 bit applications. Although Windows 64-bit can run 32-bit and 16-bit (in the MS-DOS subsystem) applications, things they think are in the kernel or shell APIs are not there.

    Another possibility here is not that there is a 32-64 issue but really that XP (almost all editions out there are 32-bit except 64-bit Pro) is the issue, not the OS bits. The XP (NT 5.1) Kernel/Shell APIs surely lack many features that the Vista and 7 (NT 6.x) APIs have.

    Would you like to help me get this thing working? You seem to be very knowledgeable with assembly and unmanaged code. I have an old machine with an Athlon XP processor and 1GB of RAM that would be a good candidate for XP 32-bit. I imagine we could find where the bug is occuring with some good ole-fashion debugging.


    Please mark any answers and "vote as helpful" any posts that help you!

    • Proposed as answer by Zock77Editor Monday, October 22, 2012 2:07 AM
    • Unproposed as answer by gungan37Editor Tuesday, October 23, 2012 10:06 PM
    Sunday, October 21, 2012 4:23 PM
    Answerer
  • The 32 bit issue is because C++ creates different dll for 32 and 64 bit and this needs to be carefully managed in compiling and linking settings since it has to be used by SmallBasic which is based on AnyCPU processor.

    There are other issues with threading keeping it running smoothly (not delaying the graphics engine while SmallBasic does its stuff, while maintaing the ability to modify/create/delete things in the engine with calls from SmallBasic without the engine trying to use something that has suddenly disappeared or changed) - these also need worked out before uploading.

    I will get it going and upload when tested a bit on 32 bit.

    Sunday, October 21, 2012 5:38 PM
  • I think the dll issues are solved and works on at lease one 32 bit machine.  All downloads for testing on my SkyDrive here

    If all is OK the next stages would be to consider what meshes people want to use and then some other game-play commands - I already added some collision detection and basic mouse selection events.

    Tuesday, October 23, 2012 8:12 AM
  • Um, when I do this:

    LD3D.Setup("True","Blue")
    Sphere = LD3D.AddSphere()

    It reports this:

    "The type initializer for 'Litdev3D.LD3D' threw an exception."
       at LitDev3D.LD3D.Setup(Primitive fullScreen, Primitive colour)
       at _SmallBasicProgram._Main()


    I am a 10 year old that loves math, games, and computers. 'Binary is as easy as 1, 10, 11.'

    Wednesday, October 24, 2012 2:41 AM
  • Oh dear,

    On both my 64 bit and a 32bit machine your code works when I add a LD3D.Start() after your 2 commands.

    Without being able to reproduce the issue, its pretty hard to see what to try?  Did it work for you before?  What OS are you using?

    One possibility is to try just native code, by downloading irrlicht and trying one of the samples in VS - a little complicated but I'm sure you could manage.

    Perhaps others can also say if they have problems and there might be a pattern, like there was with 32 bit.

    Wednesday, October 24, 2012 8:15 AM
  • Mine also reports the error saying

    "The type initializer for 'Litdev3D.LD3D' threw an exception."
       at LitDev3D.LD3D.Setup(Primitive fullScreen, Primitive colour)
       at _SmallBasicProgram._Main()

    I am on a 32 bit Windows 7


    Wednesday, October 24, 2012 3:47 PM
  • No idea, it works only the PCs I've tested it on - perhaps because they have a VS development environment or different openGL or something else.

    The type initialiser error is the linking of differently targetted processor dll types, and:

    1] C# express doesn't allow processor designation.

    2] I must link to SmallBasicKibrary.dll that targets AnyCPU, which uses different .Net native libraries and switches automatically from x86 to x64 depending depending on processor it is run on.

    3] C++ native code must target either x86 or x64 as each generates incompatible code.

    4] When using dlls, the native code must agree.

    Given I can't trouble shoot the problems, perhaps it is time to abandon the idea of using C++ for 3D extension, sorry.

    EDIT2:

    I have tried it on a second newish fairly clean Windows7 64bit PC with no development environment and it worked there so I will probably continue to develop it only on 64 bit unless I hear of other problems on this platform.  Sorry for those on 32 bit PCs.

    • Edited by litdev Wednesday, October 24, 2012 8:59 PM
    Wednesday, October 24, 2012 5:12 PM
  • I'm using a 32-bit HP Laptop running Windows XP. Was I doing the commands in the wrong way?

    I am a 10 year old that loves math, games, and computers. 'Binary is as easy as 1, 10, 11.'

    Wednesday, October 24, 2012 9:24 PM
  • No, your commands were good, in fact very good (the simplest case that fails is the best).

    I tested on 3 (Windows 7 64 bit) and 1 Vista 32 bit and they were OK, so I was hopeful.

    I am bending some capabilities to compile and link the C++ to be compatible with SmallBasic, perhaps XP is the problem?  I can't test this.

    As it is, all may tests on Windows 7 64 bit are successful (at least 3 different PCs with totally different specs, installed software and graphics drivers etc) and and they are OK (I haven't heard any user problems 64 bit Windows 7) so unless I hear different will only upload the 64bit dlls - I will always upload all code so perhaps people can solve the issues on their own architecture.

    I am sorry it isn't working, but cannot hope to guess what the issues are without a test PC  that fails.

    Wednesday, October 24, 2012 9:40 PM