Blitz3D <> HardWired/Hybrid (DX9/11) Setup & Info
Blitz3D Forums/Blitz3D Userlibs/Blitz3D <> HardWired/Hybrid (DX9/11) Setup & Info
| ||
For the new people a small explanation/installation instruction may be in order, so..****************************************************************************************************************************************** * The Un-Official: * * * * ## ## ### #### #### ## ## ## #### #### #### ## ## ## ## ## #### #### ## #### #### ### ### ### * * ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ### * * ### ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ### ## ## ## ## ## * * ### ###### ##### #### ## ## ## ## ## ## #### #### ## ## ## ###### ##### #### #### ## ## ## ### #### ##### ## ## * * ## ## ## ## ## ## ## ## ######## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ### * * ## ## ## ## ## ## #### ## ## ## ## ## #### #### ## ## ## #### #### ## ## ## #### ## ## ## ### ### * * ## * * © Ploppy 2014-2015 * ****************************************************************************************************************************************** |
| ||
| 1 - What is Hardwired/Hybrid? Hardwired/Hybrid is Ploppy's hugely ambitious go at a more modern an up to date version of Blitz3D(DX7) and more. Basically it's the long awaited, wished for overhaul and extension to it, which brings in DX9, DX11 and lots of aditional stuff such as currently, PhysX. Aim is also to make Blitz more easily updatable so it retains compatibility with future versions of DX to come. Also the possibility of a 64bit version is currently being investigated/prepared. 2 - What is the difference between Hardwired and Hybrid / How to setup? Hardwired is an extension to standard Blitz3, BlitzPlus (and even BlitzMax)in the form of a DLL that needs to be put in the Blitz userlibs folder, together with the accompanying DECLS file. E.g for Windows 7 x64, the "hardwired.decls" and "hardwired.dll" files go in here: "C:\Program Files (x86)\Blitz3D\userlibs" The Hardwired commands have a prefix of "dx" to distinguish between regular Blitz commands. Standard Blitz commands are still in place, along side the upgraded versions. The DLL has the advantage that it can be used by all languages that support this. There are initiatives for adding it to BlitzMax(see threads VI and X), but also people who have an interest for usage in Pure/Dark Basic. These spin-offs at the moment have a lower priority for Ploppy though. Once the project has been completed it's possible this will change. Hybrid is basically a merger of a reworked Blitz3D source, modernly recompiled overhauled, adjusted and extended with the functionality of Hardwired integrated. For installation just take the "Hybrid" folder and place it where you like, such as: "C:\Program Files (x86)\Hybrid". It can live right beside the Blitz3d folder. *)Note: it currently doesn't come with an installer yet, so if put in a system folder such as above, it could in some Windows versions(for instance Windows 7), lead to write permission issues. Hybrid commands do not have the "dx" prefix and programs have their own ".hb" extension. E.g: "test.hb" UPDATE: A 64-bit version of Hybrid is currently in the makings(test version released). This was/is a very complex task for it requires converting the original Blitz3d x86 VS C++ code to more up to date version, recoding to x64, plus some reverse enginering of the assembly code the does the actual x86 compiling(for as far as I understood). 3 - Is it just another DLL extension? It is not just a 'little addon', but rather a whole new world, which shows when you take a look at the already huge list of Hybrid commands*, which o.a. gives us: -DX9/DX11(possibly DX12 when released). -Shaders. -Double precision calculations. -NVidia's PhysX engine. -VideoPlayback via the VLC dll. -Instancers. -3D fonts. -Shadows. -Bones. -Webcam capture. -Touchscreen. -Collisions. -Linker directive(specify icon for final executable). -Particles. -64bit variable types. Just as 32bits are defined by % for integer,# for floats and $ for ASCII strings, they are defined by: %%, ## and $$ for Unicode characters strings. See Unicode character table. Note: currently only in 3d mode(after a graphics3d command), the 2d commands still need conversion. -Lots of additional stuff and fixes. -GUI Menu commands from BlitzPlus. -New text routines a la FastText. -Gamepad module using XInput to use PC, Xbox controllers. For PS3 controllers see here. *) List of commands and their functionality is not final and subject to change with or without notice from the author(Ploppy) as this is very much a work in progress with lots of development going on. Also the hardwired.dll contains more commands as there are a lot of reworked and upgraded standard blitz commands. Also note that some commands may be temporarily disabled for development purposes or not yet fully operational. For a list of >>CURRENT COMMANDS and PLOPPY'S LATEST DOWNLOADS << click here. Also: *** If you want to support the brilliant author and can spare a dime, do not hesitate to reward him for his hard work(even small ammounts are welcome) ***  or like him on  .System Requirements: - Window: XP, Vista, 7, Windows 8.X (32 or 64bit) - DirectX Capable GPU - DirextX: DirectX 9.0c End-User Runtime and for other versions: How to install the latest version of DirectX - For Hardwired(DLL version) Blitz3D or BlitzPlus (Hybrid is the standalone version, which doesn't need Blitz) - VLC libraries(only required for video playback of all media types): libvlc 32bit List of Forum Threads and Subjects: Direct x 9 Userlib Blitz Hardwired - DirectX 9 Userlib (Part II) Blitz Hardwired - DirectX 9 Userlib (Part III) Blitz Hardwired - DirectX 9 Userlib (Part IV) Blitz Hardwired - DirectX 9 Userlib (Part V) Blitz Hardwired - DX9 and DX11 Userlib (Part VI) Blitz Hardwired - DX9 and DX11 Userlib (Part VII) Blitz Hardwired - DX9 and DX11 Userlib (Part VIII) Blitz Hardwired - DX9 and DX11 Userlib (Part IX) Blitz Hardwired - DX9 and DX11 Userlib (Part X) Blitz Hardwired - DX9 and DX11 Userlib (Part XI) Blitz Hardwired - DX9 and DX11 Userlib (Part XII): - Hybrid Help and IDE. - Various fixes - B+ Gui command set introduction. - Monkey DLL + stuff by BlitzSupport. Blitz Hardwired/Hybrid - DX9 and DX11 Userlib(Part XIII <<current): - GUI Menus commands from BlitzPlus added. - Work on x64 Hybrid. - Adding new text routines. - Added gamepad module using XInput. Some more FAQ's: 4 - Is it free? Yes. Ploppy stated it is and will be free.(Initial release at least. He's free to change is mind of course.) 5 - Is it open source/can I collaborate -help the author? No and yes. Ploppy doesn't want this to be an open source collaborative project, but his own personal achievement. He has stated that if for some reason he has to give up, he will release the source to the community for someone else to pick it up. Not to worry though: Ploppy is very committed and not very likely to throw the towel into the ring. He likes feedback though from testers and is open to suggestions as long as reasonable. However please do not harass the guy with too many requests as it is a massive task already. 6 - How do I make use of the video playback feature? Libvlc is a free library, available on http://www.videolan.org/, and is the core of the popular VLC Media Player. To be able to use this, you will need to copy the files 'libvlc.dll' and 'libvlccore.dll' together with the whole of the plugins folder (copy folder and its contents) from the installed libvlc folder to your bb project folder(for example where you unzipped the latest release: D:\Coding\Blitz\Release\ ) Please note that these files and folder are *not* to be copied to the userlibs folder, but to the folder where your compiled exe/blitz .bb file is located. *)Note: I couldn't play any video until I copied the video file into the same directory as the release, but that may just be at my system. You'll have to install these files only in order to get the video functions to work. If you do not wish use these functions, the files do NOT need to be installed, and hardwired will behave as normal. If you use these funtions, and these files are not installed the video functions will not work, but should not stop your program from running otherwize. *)Note: The 64bit version of VLC is not currently supported! To make the installation of the video capabilities of hardwired easier, Ploppy has supplied the libvlc 32-bit dll files in a separate zip file (28MB), if you wish you can download and extract the files directly to your bb app folder. This archive file includes *ONLY* the required dll files & plugins folder, and not the whole VLC Media Player thing(handy if you already have the x64 version installed and don't want the 32bit also: Download libvlc 32bit 7 - Why can't I play audio in Hybrid? The audio commands in Hybrid are not yet build in. Ploppy has to still decide on an audio library as the original build into Blitz3d requires a license, therefore he's looking for a free one. Several options are under review. The Hardwired DLL, useable from Blitz3d does work with sound, for it's using the original Blitz3d routines. 8 - How do I use shader programming? Shader programming is done through a specific GPU scripting language named HSL and apparently can be very powerful, but also kinda tricky. In the examples there's a folder "release\samples\shaders" which contains examples. Here's a link that was provided by Ploppy regarding HSL: http://www.catalinzima.com/xna/tutorials/crash-course-in-hlsl/ IMPORTANT: Hybrid's currently undergoing lots of changes as Ploppy is attempting to convert it to a 64-bit version, needless to say this takes quite a bit of time. Also it appears Hardwired or it's examples haven't been updated yet to the latest incarnations so a lot of examples may not run at the moment. This is a work in progress so may contain bugs and is subject to change. However the author is very committed to the task and will respond to bug reports, but please do take into account that he has a life besides Hardwired/Hybrid. ------------------------------------------------------------------------------------------------------ Below is my original post. Topic: Converting a 'little' :-) test program for Hardwired. Updated code and including media (24.73MB) is available for download here, for those interested in testing Hardwired/ Hybrid's compatibility with Blitz3d. Currently there aren't extra Hardwired/Hybrid functionalities build into it appart from DX9/11 stuff. ------------------------------------------------------------------------------------------------------ |
| ||
| EDIT: The test program is now fully functional, since some updates ago. You can see the progress in development, reading the topics below. Hi ya all(especially Ploppy), I was perhaps a little overly enthusiastic and was trying to do a bit of code conversion from Blitz3D to HardWired. To be specific: I wanted to convert some Planetary code of mine as a testbed for HardWired, but then I came across Krischan's excellent code(credits to him) and ditched my own as his code was far superior(of course: he's a genius). I just added and changed some minor things to it. Now the thing is that it works just fine as Blitz3D code, but when I converted all commands needed, I'm getting a black screen and then a MAV. If anybody has a clue what's wrong here I'd be happy to know, cos I tried a number of things, but no success yet. Looks like this:  2751(Interplanetary travel)9.bb (adapted) |
| ||
| 2751(Interplanetary travel)9HW2.bb (adapted) |
| ||
| Been playing around with this, and after about 2 hours, I've at least narrowed it down to the loading of the ship mesh in InitScene! It does appear to successfully load it (SHIP has a value), and goes into the main loop, then crashes on dxRenderWorld, so I assume the HW renderer doesn't like something about the model... If I comment out the SHIP dxLoadMesh, and the following commands operating on SHIP, it does at least go through the main loop, displaying the text overlay. Beyond that, it's over to Ploppy! |
| ||
| Hi Rick, I have found a little problem in my dxLoadMesh routine that I have corrected. It seems that your b3d mesh has invalid triangles in it that make reference to vertices that have not been defined. My routine did not error trap invalid triangles- so I have now written the code and the model correctly loads now. I am however not yet ready to re-release new version. I have, thanks to your code, been able to ascertain a few errors concerning rotations, so I'm going to sort that out first. Your demo will not work well at all in HW without this correction. @BlitzSupport - Thanks for your help on this, it was indeed the model loading that was bugging out.... |
| ||
| Woo-hoo! Well done, Ploppy. |
| ||
| Many thanks BlitzSupport & Ploppy. Was cracking my skull over it. Indeed when in InitScene() I comment out: ;SHIP=dxLoadMesh("GFX\286428main_shuttle-hi-res\shutD2F3.b3d",SOLIDPIVOT) and replace it by the cone in the line above as such: SHIP=dxCreateCone(16,1,SOLIDPIVOT) It then it at least shows something. Even though not perfect yet, it's encouraging to know that HardWired IS able to do it:  |
| ||
| Hi Rick, just to say that I'm still working on it but I have made a lot of progress. Your source code has definately given me a challenge and helped me discover many bugs I has not yet seen. Anyway, things are really starting to take shape. Your b3d models bundled with your code contain references to textures that are used on the mesh. I hadn't yet implemented that part into my b3d parser, so I'm working on that at the moment, as is the case for brushes. Thanks for the help, please feel free to feed me more code - especially stuff that makes HW behave strangely. It helps me pinpoint bugs. Ploppy.. ;D |
| ||
| I'll see what I can do. :-) |
| ||
| Hello Rick, I have just released a new update for Hardwired. I decided to let you know about it on this thread as the update mainly concerns your source code. I have been working with it the last few days, testing and testing, and I have almost corrected it all now. Looking much better now, dxLoadMesh will now automatically load textures for b3d models just like b3d does. Local scaling has also been corrected, and your source seems to work much better. When you get the chance please check out yourself and let me know what'cha think. New update As always, thanks for your support. |
| ||
| Hi Ploppy, many thanks. Sorry missed this one. Did I blink or something? Oh no, couple of days gone again lol. Was a bit preoccupied with some new additions/tweaks to the planetary system. Tested HW just now and still sort of the same I'm afraid to say: very hard to stabilize the cam, at least when moving the mouse. Also happens when using cursor keys, but less as is more of constant input, then only noticeable by it sometimes jerking, speeding up, especially when the object nears edge of screen. In areas where there's little gfx it's speeding up, while in places with a lot of gfx it slows down. It least that's my impression of the issue and would explain the erratic camera behavior. It seems there's no timings/correction/compensation at work, which becomes more noticeable the more gfx are in the scene(with possibly a slower CPU/GPU as mine?) in combination with nothing at all, such as in space. I had noticed this before in for instance test7.bb when at the wall like object, the cam is moving slow, then when moving the mouse to the right the cam jumps and is very hard to get back into the previous position as it skips over it. I thought in beginning this was intended behavior you wanted to check things with or correct/make use off at a later stage, but it does defer from how Blitz3d normally behaves. Could be I'm completely off and that there's another explanation for this, it's just what I think is going on. Hope it helps. |
| ||
| OK bit of an update to this, for I might be wrong. What appears to happen is this: I start the program and after it initializes the cam goes weird and gfx fly all over the place. Then if I try cursorkeys in like 5-10 seconds it starts to behave normal, even when using the mouse for control!(?) This is really weird. If do not manage to gain control within like 15 secs or so then its not gonna happen again until restart. Can it be mouse is not being properly addressed? Also I noticed the LeftShift key gave the correct slow speed value, but the RightShift key acts as if LeftShift was pressed, while should give high speed. Another thing I noticed is that wiredframe shows upon the earth sphere when in close up. |
| ||
| Update nr 2: Spaceship now does show up, even though bright white untextured. And I when I managed to gain control, I can also press keys 1-0 to jump to planets, but pressing S-key doesn't show cam in rear of ship as should, or perhaps it does but it doesn't show up, so followcam fails. Perhaps it's at the wrong distance related to ship cos was kinda tricky to establish in the first place in vanilla Blitz3d, probably cos of scales. |
| ||
| Thanks for detailed assessment Rick. I will try to iron all this out. It seems there are still some bugs in some of the more basic commands. |
| ||
| Anytime. ;-) Hopefully this makes things more clear. |
| ||
| Hello Rick/BlitzSupport, I have made significant progress with my userlib and this project, so I have uploaded an update. I have also reuploaded the hardwired version of 2751(Interplanetary travel)9HW2.bb because I think you must not have converted it correctly to hardwired the first time. So I have re-converted it, it took the original source 2751(Interplanetary travel)9.bb and put a dx in front of any commands that require that and inserted the default parameters into the functions that expect them. Otherwise, I have not modified it in any way - to all intents and puposes, it is the same, but using hardwired... 2751(Interplanetary_travel)9HW2.bb  Hope you like the improvements - it's getting there now, I'm happy with the progress made today. :D |
| ||
| Ah.. the shuttle is showing it's textures properly now, good pne. I'm making an assumption her but could it be you have given left and right shift keys the same code? for if I press the right shift it reacts as if I pressed left, thus giving the cam speed a value of 0.05(slow) while should be 5.0(high) when pressed right. Also when first starting, the cam or mouse spins out of control, like as if it's making circles very fast, then when I zoom out it stabilizes and I can zoom in again and all goes well. Suffering bit less camera jerking/pauses/hick-ups when going from busy to empty area now but still noticeable. Another thing, but less important, is that the orbit/trajectory lines appear bit thick, probably no alpha yet? Overall it appears to be bit more sturdy. Many thanks. |
| ||
| Hi. I presume this is the current post running for hardwired lib. Hybrid.exe crash on Windows 8.1 ( Blitzcc.exe crash in fact ) \ Test1.hd It work's well on W7. |
| ||
| After recent updates by Ploppy, now appears to be working fine and stable. Will examine more closely and release updated version over time. |
| ||
| the following question is really no joke. how fast is the 2d engine? can i redraw 3x 1024x786 images at constant 60 fps? btw. second question from me: without reading whole topic: what was the adaptions making the demo working? |
| ||
| I'm getting "unable to find directx 9 on the resident system..." etc. I have win 8.1 / dx11. The dx11 test doesn't work either. Ideas? |
| ||
| -2d? no clue. Correct me if I'm wrong but afaik 2D in DX is just the similar to writing on 1 side of a 3d cube. Redrawing an image of that size should be feasible in my opinion but haven't tested anything like that. -Basically adding "dx" in front of all commands and leaving out some of the more advanced stuff that wasn't necessary for testing. I see the archive is no longer avail, so I'll re-upload, later today, otherwise no media. |
| ||
| @stayne, I don't think your dx9 is completely up to date -it's happened to a few people already. Just google directx and download from the microsoft site. This will check and install the latest version. |
| ||
| That did the trick thanks Ploppy. |
| ||
| Ok |
| ||
| Nice work, looking forward to see more of this. I get a "Unknown runtime exception" on some (most) examples though, using a Surface3 how to solve that? |
| ||
| No clue, perhaps an Win8.1 issue? Tried compatibility mode(rightclick, select properties..)? |
| ||
| @Ploppy: Hmm.. Was comparing the output of the 3 versions of the test program like this: A. 2751(Interplanetary travel)9HW2.bb (my original conversion) B. 2751(Interplanetary_travel)9HW2(plop).bb (Ploppy's conversion) C. 2751(Interplanetary travel)9.bb (the Blitz3d version ran from Hybrid) D. 2751(Interplanetary travel)9.bb (the Blitz3d version ran from Blitz3d itself) Outcomes: I) I couldn't see differences between my Hardwired conversion(A) and Ploppy's(B), or at least for now. II) When comparing between the two Hardwired versions(A & B) and the vanilla Blitz3d version run from Hybrid(C) and Blitz3d(D) itself, I've noticed the following: -II.1) First thing that's obvious is the difference in lighting/coloring of the sun rays gradient(which is a quad). It appears the range is less gradual, the transision less detailed than under vanilla Blitz3d. My guess is that this can be fixed by adjusting the shader stuff somewhat? -II.2) The controls are less smooth than in Blitz3d: when moving around the solar system passing by an area with less gfx it speeds up the movement, while in an area with more gfx elements the movement slows down. This causes a stutter in the controls, making the movements less smooth. This is something I've noticed from the start of the Hardwired project in the accompanying examples, but comparing between the same code in vanilla Blitz3d and Hardwired/Hybrid makes it more obvious. I'm guessing in vanilla Blitz3d there's a balancing system for the timing to keep updates smooth and in line with what's to be expected. Or is this also a result of shaders? Is there a way around this? |
| ||
| Just wanted to add that I like what you created from my interplanetary travel code, Rick :-D And I didn't knew the space shuttle could fly THAT fast ;-) |
| ||
| @Krischan: Well, it's not the full thingy I did within Blitz3d. I've added your Milky Way and your Saturn shaded rings, added an asteroid belt (no billboards) and more. Not perfect yet though(reverse rotations, tilted orbits,real/virtual time switch, satellites and all that and just noticed Earth's atmosphere is too thick). When I get the time I'll have another go at it. 64bit would also help for calculations to add detail to the movements(bit jerky the larger it gets). SpaceShuttle: It's the latest secret upgraded model they don't tell us about. ;-)      (screenshots from the updated vanilla Blitz3d version) But I'm sure you have a better version incorporating all the modules you've produced over time. I'm more than curious to see what it looks like. |
| ||
| Hi Rick. I too have noticed some speed anomilies within hardwired. This is particulrly apparent in my maze demo. Sometimes the fps really goes down when turning the camera. I think I may have badly configured the z-buffer but I haven't pinpointed it for sure. Funny thing is that in directx11 mode I do not get this problem. This may be related to your jitter problem in your demo (like the asteroids, btw). However, you may get a smoother frame rate if you set vsyn on (if it isn't already) with dxFlip true. But I don't think that is the heart of the problem and there's something I'm missing I do have to sort out in the renderer. I will look into but that's only one of a whole heap of problems I have to look into. Keep those bug reports coming though when you have time. There are undoutably some things I have not noticed and it's even better to have example bb code to help demonstrate bugs. |
| ||
| *************** * BUG REPORTS * *************** @Ploppy: Bit of rain on the parade. Compatibility issues regarding Unicode? Ran in Blitz3d with Hardwired dll and decls installed:  As you can see, things show up in Chinese. Shouldn't it be that default is ASCII to retain compatibility with earlier/vanilla Blitz code? Ran in Hybrid also:  Window title: "Output Window(Not Responding)" Pop up msg: "blitzcc.exe has stopped working" Problem details: "Problem signature: Problem Event Name: APPCRASH Application Name: blitzcc.exe Application Version: 0.0.0.0 Application Timestamp: 55255b7b Fault Module Name: runtime.dll Fault Module Version: 0.0.0.0 Fault Module Timestamp: 55256442 Exception Code: c0000005 Exception Offset: 0006fdb3 OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 1043 Additional Information 1: 0a9e Additional Information 2: 0a9e372d3b4ad19135b953a78882e789 Additional Information 3: 0a9e Additional Information 4: 0a9e372d3b4ad19135b953a78882e789" [UPDATE after latest release] Hardwired: no more Chinese. Hybrid: still crashes with above error code. Is there a difference in the Hybrid version? |
| ||
| Freaky stuff, thanks for the bug report. Check out my latest release, it may fix it - please feel free to let me know if it doesn't as I need to know these kind of things. Cheers as always.... Edit: Rick, can you give me/send me an example that I can test out here? If not, try to see where it bugs out if you have time. Either put debug mode on, it may show you before it crashes (though I don't think it will), or insert an End statement somewhere (half way is a good start) in your code and test to see if crashes. If if doesn't crash move if further down the code and test again, if it does crash move it up in the code until it doesn't crash any more. That way you can isolate the line of code that makes your program crash and you will be able to tell me the command that is giving you trouble. Thanks. |
| ||
| Hi Ploppy. I'm just using the test same code as before, nothing exotic(see post# 28 above) to test if things keep running smooth and sound. I've tested with debug enabled and disabled, but no difference this time: in Hybrid it just crashes with error report above. The Hardwired version doesn't have the Chinese characters anymore and seems to be running OK, apart of course from the earlier mentioned pause when more complex gfx are in view and speed up when less in view. The latter may be mouse control related, I'll check for you if also happens when just using key controls. I will also prep a test package so you(or others) can test for yourself. |
| ||
| Does Hybrid crash with every program or just some on your system? |
| ||
| @Ploppy: Few things.. - Indeed I noticed the same thing as Virtlands(Request File error) and mentioned in my latest post. - I also found that AppTitle doesn't appear to work. - Can't get my testapp to run in Hybrid though. I assembled a downloadable test set here(incl. media 24.73MB , so you can crosscheck my findings regarding the testcode I was running. This archive contains: 1. "Interplanetary travel_2751_Original version by Krischan.bb"- As described in title(the most bare Blitz3d version). 2. "Interplanetary travel_Blitz3d version.bb" - A modded version of above code. Can be run under original plain Blitz3d and Hybrid to test compatibility. 3. "Interplanetary travel_Hardwired version.bb" - Same as above, but all commands converted to their Hardwired equivalent(prefix DX) 4. "Interplanetary travel_Hardwired version revised by Ploppy.bb" - The same as version above, but revised by Ploppy. 5. "GFX" - Folder holding media freely available from NASA. Test Results so far: For Hardwired: Thought I was going nuts, or my system was having issues, so decided to go back a few versions and put these older DLL and Decls in the Blitz3d UserLibs folder. Now by testing something became clear to me: Blitz3d actually also checks and uses the hardwired.dll/decls that are in the same directory as where the file you are trying to run is located and executed from.(e.g: "maze.bb"). I didn't realise that before. Sorry I missed that one. Ahum. Perhaps better to put them in a separate folder "userlibs" to avoid confusion? -With the new dll/decls versions that introduce the types %%,##,$$: 1. "Interplanetary travel_Blitz3d version.bb" working fine(should be as is bog standard Blitz3d) 2. "maze.bb" is not working "User lib function not found".Debug points to >> font=dxLoadFont("times",18,True,True,0) << also goes for most other test examples. 3. "test2_physx.bb".( conversion from .hb file, included below): all fine. 4. "Interplanetary travel_Hardwired version.bb": all fine. For Hybrid: I was running Hybrid from the "C:\Program Files (x86)\Hybrid" for ease of use(windows knows to execute the Hybrid.exe once taught the .hb file type) but ditched that to have more control over which version to use. -Older version(the latest particle version): all fine, can run all; 1."Interplanetary travel_Blitz3d version.bb" (so fully compatible with blitz3d). 2."maze.bb" 3."test2_physx.hb". -Newer version(the x64 type introduction): 1."Interplanetary travel_Blitz3d version.bb" crashes with a gray screen and error "Blitzcc.exe has stopped working". 2."maze.bb" is OK. 3."test2_physx.hb" has error "Incorrect function return type" on the "RequestFile$" command. Questions: - Does Hybrid break compatibility with previous Blitz3d code due to defaulting to x64 ##? - If so then better to do a separate x64 version otherwise lots of converting to be done for existing Blitzers? - May I ask in what path you've installed Hybrid? * Perhaps someone else can also try to verify if my results are replicable? |
| ||
| Hi Rick, it is true that especially due to the introduction of the new unicode string, there are a few functions that sway away a little from the blitz standard. The only real change is that for some bb code, small changes will have to be made in a function's return type. For example Blitz3d's CurrentDir() function uses the standard string type '$'. In a blitz3d program, you can use the command CurrentDir() as for any string returning function in two ways... 1> a$= CurrentDir() 2> a$= CurrentDir$() I know that personally I have the habit of using the second version. Other people than me probably do too. I was brought up with basic, and started programming in the 80's with a ZX81, so was used to this kind of syntax with commands such as Chr$. This way of coding hasn't left me, and is not likely to. Both methods in B3D are acceptable, if you use the first method, the compiler will return the type that is defaultly configured for the function in question - so the result is the same. If however you try using another type in it's place... a$=CurrentDir%() ...you will get an error message 'Incorrect function return type'. This is because the function is not configured to give it's return value in this format. All of the above is also true for Hybrid. Most of the compiler and it's solid rules have remained intact on this front. Like I mentioned in my worklog, I have reconfigured certain basic commands to now return unicode strings rather than standard strings. Now the default return type for CurrentDir() is $$. So now the two methods below are now valid... 1> a$= CurrentDir() 2> a$= CurrentDir$$() Any other type (including the old default return type) will now be invalid, and the compiler will indicate it so. So, I do understand that for some programs this could be a little annoying to have these errors, but all you need to do to correct them is to change the return type of the functions in question. Or, to maximize compatibility between both B3D and Hybrid, you can just choose method 1 of the above which work both as effectively on both compilers. This way you have no errors and will not need to edit your code each time you change compilers. I understand that this could be inconvinient for some, but for most people and most code, you will only need to edit a few lines eliminate these function return type errors and all is once again normal. I still believe however that unicode is a good and more modern approach to programming, accessibility is much improved and gives so many more options - this is why I wish to adopt this standard for my functions. If the programmer does not wish to use unicode strings of course he doesn't need to and can continue with standard strings with complete transparency apart from keeping with the return type rule. I'll let you know about the rest tomorrow, cheers for the thorough test Rick - I really do appreciate... |
| ||
| You're welcome. :-) I do get where you are coming from cos I myself started out with the ZX81(was lent to me for 2 weeks by my cousin), followed by an Aquarius(don't ask ;-), C16/C64's and Amiga500/1200's.CHR$(13) I really see method 1 as sloppy programming and do see Unicode as a big improvement. However one of the benefits of Blitz3d is the extensive amount of code in the code archives/forums, of which quite a bit is using sloppy method 1, but also method 2, and that potentially could frustrate a lot of people. Especially beginners I fear could get confused and abandon ship. For that reason I personally would have chosen it the other way round to retain max compatibility, so people could just keep running the old code, and when in need for Unicode, exclusively declare that by using $$. But I can imagine it would take ages of recoding and me, myself and I can live with it perfectly fine as is of course. |
| ||
| If only things were that simple! In fact, now that I know what to look for and in what parts of the code I need to configure these string related commands, converting them back to normal string return type is not a time-consuming task so no bother for me. But this is not the problem unfortunately. If for example you keep the CurrentDir$() as the default B3D function and you assign it to a unitype string variable... a$$=CurrentDir$() The variable of a$$ would contain the output of the currentdir function, which is of course of a single string type. If the name of the current directory contained a unicode character (who is to say that some people do not name thier folders/files with thier own alphabets?), the output of the CurrentDir$ function will not contain these characters because an ascii string doesn't support any code above the 1-byte limit. So assigning it to a unicode variable is definately possible, but it would already be too late. Since the output already lacks the unicode characters, converting it to unicode would still only contain the ascii characters. One could say lost in translation (boring film IMHO - watch it when drunk, goes by faster...) If however, the CurrentDir$$() function is configured to output its result as a unicode string nothing is lost. If you then assign it a unicode variable no change needs to be made and again nothing is lost. If you assign it to an ascii string the unicode string will be converted - if it contains any unicode characters the variable will of course not contain them and will be converted to a question mark or a square character, which is found in the ascii set. |
| ||
| Ah, I see what you mean. Rather impossible indeed. Interesting insight. BTW: nice fix for the IDE. Ran test2_physx.hb in it: all fine, playing the audio & video, but as long as the video is in same directory. Still can't run get "Interplanetary travel_Blitz3d version.bb" yet though. Using the debugger manually(inserted 'stop' command) I managed to pin point where things go wrong: Function Initialize() Local p%,m% Local parent%,name$,radius#,period#,size#,r%,g%,b%,plt$,mnt$,rtp# Local speed#,entity%,random%,orbit%,atmosphere# ; read planet data Restore PLANETDATA For p=1 To PLANETS Read parent,name,radius,period,size,r,g,b,plt$,rtp#,atmosphere# ; <<< in this line So guess it's variable related. |
| ||
| I may however create two versions of each function that returns a string.... CurrentDir$() UniCurrentDir$$() ...for example. This would bring compatibility back and at the same time keeping the option of being able to manipulate unicode strings. I'll think this over... |
| ||
| Might be a good idea, if feasible. Did you see my above post? Any clue what's causing this? I've tried defining the variables, but still the same crash. |
| ||
| @Ploppy>>If i am interested to convert some of my codes in hardwired, can i run 2 Blitz3d ide ? One with the blitz3d code, one with the hardwired code ? And will i be able to compile and to run both versions (one at a time) ? If yes i will try to convert some of my codes in hardwired and maybe help you to find bugs. Thanks, |
| ||
| Hi RemiD, Yes I think you should be able to run both B3D and Hybrid at the same time if that's what you mean. @Rick, I have just uploaded another update for Hybrid and I have tested it out on your interplanetary demo - it works now. |
| ||
| @Ploppy>>And can i run 2 blitz3d ide, one with blitz3d code (syntax and functions) and the other with hardwired code (syntax and functions) and will i be able to compile and run both (one at a time). This way i can code in Blitz3d (syntax and functions) and code in Hardwired (syntax and functions) and test both codes (one after the other). |
| ||
| @RemiD: I think should work. Did it in the past, while was converting Blitz3d code to Hardwired. |
| ||
| @Rick>>Ok i will try, thanks. |
| ||
| In this lib does draw image use biting like BLITZ3D or does it use hardware acceleration like Blitz max ? |
| ||
| When not in Graphics3D mode, hardwired/hybrid will use the standard original blitz code (in other words, Blitting) - I may change this later. However, it will use the directx surface manipulation routines in 3d mode. |
| ||
| So ploppy if I use Graphics3D , drawimage will work like BlitzMax? where the 3D hardware handles the drawing ? |
| ||
| To my knowledge, that's right. |
| ||
| I will have to test this then. Does that mean you may be adding things like rotation, color, scale ect to drawimage ?? |
| ||
| Yes. I plan to cover pretty much 99% of the original b3d command set. The only thingd that are not likely to be covered are the bsp routines. |
| ||
| no support for bsp routines!? no support for fast collision system (octree-only is not acceptable!)!? :--O since peoples read that, nobody is using HardWired/Hybrid anymore ;..) Please do not missunterstand my posting. Many software are the mega-hammer products but never really used since important feature(set) are missed. Compare the UE4 with Cryengine. Compare unity with Cryengine. Cryengine is the BEST. But it lags on ->fast<- team-working-features. Making the same great game with UE4 is faster than creating it with Cryengine. By the way.. the creators of the cryengine had big financial problems trough lackin features like that Oo I can not unterstand you. HardWired/Hybrid is based on a fork of Blitz3D-Source. Why cutting bsp feature!? |
| ||
| If you can convince me of its utility I'll include it. I just had the feeling that bsp was not used any more... Hardwired is not based on a fork of the b3d source. I started work on it wayyyy before the blitz source was released. |
| ||
| Guys - just one little thing, please use my thread for all things Hybrid/Hardwired. It's easier for me to follow that way, and all related discussion remains together in the same place. This is Rick's thread, focusing mainly on the topic of testing hardwired especially with his interplanetary demo. |
| ||
| Sorry. I had not know that you wrote the hybrid compiler etc. too By the way... please play the game "neverball" (google it). It is a modern game with realy nice graphic and is using bsp maps. |
| ||
| delete |
| ||
| I did say that Hardwired was created before the release of the b3d, I was very clear about that. I never said that Hybrid was however created before the release of said b3d source. Hybrid is indeed based on a fork of the b3d code. However, as the name suggests, Hybrid is an offspring of b3d and hardwired together, and Hybrid and Hardwired should not be confused as they are different entities. Hardwired is a userlib dll and Hybrid is a combination of this userlib and a customised version of the blitz compiler. The whole of the hardwired engine's code and all routines are kept within Hybrid. For any 3d based command called using Hybrid, calls are made directly to the internal hardwired lib, just as you would by calling a userlib function. These routines are independant of the blitz routines; even though they are called by them and the compiled program. Management of all related hardwired object types is completely done by hardwired. Since the base hw routines were programmed before the release of the b3d source combined with the fact that hw uses dx9/dx11 and not dx7, all of the the 3d routines from the original source are not at all compatible with any hw routine so they would have to be converted if needs be. In hybrid, the main program, statements, string/file/bank/array handling, expressions and basic maths are indeed managed by the b3d compiler/runtime which of course came from the b3d source. If I count on including BSP handling routines, I need to create my own routines that fit in with the rest of the hardwired architecture - I can of course take inspiration from the old b3d source; but changes/additions have to be made. This takes time. It doesn't bother me too much about including it but I have to judge it being worth it. If you think it is, I'll have a look into it - I have to say that I do not know a lot about bsp trees for the moment. Hope that's clear... P.s. Neverball is pretty good fun, reminds me big time of Hamsterball that I have for the ps3... |
| ||
| Krischan did a nice demo for BSP trees, which looks pretty good(as all of his stuff): http://www.blitzbasic.com/Community/posts.php?topic=90144 and here something related: http://www.blitzbasic.com/Community/post.php?topic=89714&post=1019762 Looks like a hassle to set up and all, but may well be worth it. Dunno how much it´s being used in the industry though. |
| ||
| Krischan is using a modified version of the file format. This is a "no go". The sources in the code-archive are not compatible with large maps (original blitz3d). Today you can ignore bsp leafs/node management. It is sen the bunch of polygons to ya octree engine :-) See that: I have not the time writing a editor for my game. I have only the time writing my game. The question is now: Wich userbase do you support with ya engine? Mainly creating a game or creating editor-apps? :-) |
| ||
| Hi ShadowTurtle, The user base I am aiming at is anyone that is interested. If they are, that's great. If not, well - it's for free, so it's not going to affect my sales ;D As for Hardwire's nature, I intend to add as many functions so that it is able to access most kinds of hardware if possible and to make the most out of directx9/11 capabilites (depending my own capabilities of course). So the kind of software developed using it should principally depend on the programmer's imagination - I hope that Hybrid/Hardwired will be able to give as many if not more programming options than b3d does... |
| ||
| .. |
| ||
| ShadowTurtle! OMG! GO AWAY! You got our thread locked because of your stupidity! Thanks ALOT for NOTHING! |
| ||
| So...new thread out, n°13- hope it's luckier than n°12, see you there! Hmmm... I'm not a superstitious kinda person but perhaps I should just start a thread n°14 immediately ;D |
| ||
| @Rick - I was thinking of including a text-file version of your beginners FAQ, I have noticed that still some people haven't noticed that there are two versions of my project included in the release and I'd like to make it clear the differences between HW and HY. Is that ok with you if I include that as a file? |
| ||
| [EDIT: updated main info text] |
| ||
| How does this work? I mean what do I do to use this? |
| ||
| http://www.blitzbasic.com/logs/userlog.php?user=13255&log=1897 The DLLs go in the same directory as your main source file. The DECLs files go inside Blitz3D\Userlibs most-likely in your Program Files (x86) folder. Then just read the examples & help documents on how to use Hardwired. It's not that hard, pun not intended! :) Hope this helps! ~GF |
| ||
| Scroll allll the way up and check: 2 - What is the difference between Hardwired and Hybrid / How to setup? |
| ||
| What happened to the Facebook page? |
| ||
| Sad news. See <here> :-( Ploppy's last postings on his work to Hardwired/Hybrid: Hardwired/Hybrid - DX9 and DX11 Userlib(Part XIV) |
| ||
| Nasher, can you ask his wife if it's ok to release his source as open source so people can continue on with his legacy? I'm not good at C++ but I'm sure someone else is! I want this dedicated to him! I'm very honorable & prideful when it comes to saluting someone! Thanks alot, Rick! Regards, ~GF |
| ||
| Hi, yeah I indeed explained to her that he always mentioned he wanted to release the source in event of him being unable to finish his work and as you can see she replied in the register that she will have cousin look at it. Hope they will be able to do so and someone (or more in a joint collaboration) can pick up where he left off. Keep your fingers crossed I'd say.. (you're welcome) |
| ||
| Thanks, Nasher. :) ~GF |
| ||
| @Rick Nasher Is there a version or the latest where animated meshes are now working? thanks |
| ||
| Not for afaik. Ploppy was redoing a lot before lightning struck. Last thing I know was his comment about it: Anyway, I seem at the moment to be on a roll with my new skin/bone and animation routines. I have completed and testing my animation routines, comprising of complete control over separate animation sets for each mesh surface. These animation sets comprise in their turn complete management over sequences, nodes and keys. We all know what happened then: radio silence, followed by the dreadful news from his wife. After her comments on the matter I haven't heard anything anymore. Hope all is fine with her and the kids. :-( |
| ||
| Thanks and really unfortunate. On a lighter note, I hope we can get hold of the source so his legacy would continue in some form or another and not into obscurity. Again thanks to Ploppy for this awesome work. |
   |