Hardwired
Community Forums/Showcase/Hardwired
| ||
| Hardwired/Hybrid - DX9 and DX11 Userlib(Part XIV) This is a so-to-speak unofficial release update of hardwired. For some time I have been working on many parts of hardwired and hybrid and I have had to 'dismantle' both in order to do so. This is why updates have been very infrequent since july. I am now beginning to put it all back together with the new code incorporated. This is the first instance of the new release. This prerelease contains some code that has not yet been re-activated - this is why it may act exexpectedly compared to the previous release. And this is also why I recommend you do not decompress this pre-release to the same folder as you do for the previous releases. If I am uploading this pre-release it is to see mainly if you have any problems on your system with the new module I am testing, a compatibility test if you like. Please report on this thread if you have any crash issues on your system. The module I am testing is the new HLSL precompiling module. If all is good, you can now compile HLSL shader code within the blitz code using the IDE. Please see hlsl_demo.hb and hlsl_demo_with_compile_error.hb for example. Please also note the the hlsl_demo_with_compile_error.hb sample program is designed NOT to work, but to show that the precompiler detects and signals any errors found in HLSL code. The HLSL precompiler compiles any HLSL code integrated into it before the program code is compiled, and the compiled shaders are incorporated into the final compiled .exe code. In this way, any shader compiling time and error checking will not be necessary during runtime of the program, as it will already be done :D As you can see, the precompiler considerably changes the look of the IDE. Hlsl code can now be incorporated into Hybrid's code by using the new Script command. This command's syntax is the following.... Script identifier(entry_function$,shader_version$,flags%) Parameters... identifier - a user chosen label used to identify the script. This unique identifier is used as reference in order to be able to 'recall' the shader's compiled code when in runtime. If the identifier supplied in the Script command has already been used, the compiler will return an error. entry_function$ - refers to a string designating the name of the function held within the HLSL script that is called when the shader is executed. This parameter is case-sensitive, and obligatory for the precompiler to work. Failure to supply this parameter or to supply an inexistant function name will result in a HLSL compiler error. shader version$ - a string containing information of what kind of shader the following code contains and the version number of the HLSL code. Valid parameters are... "vs_1_1" - Reperesents a vertex shader, version number 1.1 "vs_2_0" - Reperesents a vertex shader, version number 2.0 "vs_2_a" - Reperesents a vertex shader, version number 2.a "vs_3_0" - Reperesents a vertex shader, version number 3.0 "ps_1_1" - Reperesents a pixel shader, version number 1.1 "ps_1_2" - Reperesents a pixel shader, version number 1.2 "ps_1_3" - Reperesents a pixel shader, version number 1.3 "ps_1_4" - Reperesents a pixel shader, version number 1.4 "ps_2_0" - Reperesents a pixel shader, version number 2.0 "ps_2_a" - Reperesents a pixel shader, version number 2.a "ps_2_b" - Reperesents a pixel shader, version number 2.b "ps_3_0" - Reperesents a pixel shader, version number 3.0 The above version profiles are compatible with both directx9 and direct x 11. However, the following remaining profiles are ONLY compatible with dx11. "cs_4_0" - Reperesents a compute shader, version number 4.0 "gs_4_0" - Reperesents a geometry shader, version number 4.0 "ps_4_0" - Reperesents a pixel shader, version number 4.0 "vs_4_0" - Reperesents a vertex shader, version number 4.0 "cs_4_1" - Reperesents a compute shader, version number 4.1 "gs_4_1" - Reperesents a geometry shader, version number 4.1 "ps_4_1" - Reperesents a pixel shader, version number 4.1 "vs_4_1" - Reperesents a vertex shader, version number 4.1 "cs_5_0" - Reperesents a compute shader, version number 5.0 "ds_5_0" - Reperesents a domain shader, version number 5.0 "gs_5_0" - Reperesents a geometry shader, version number 5.0 "hs_5_0" - Reperesents a hull shader, version number 5.0 "ps_5_0" - Reperesents a pixel shader, version number 5.0 "vs_5_0" - Reperesents a vertex shader, version number 5.0 flags - Options to pass to the precompiler. Presently there are only two flags available... 1 = Do not compile this script into a directx9 compatible shader 2 = Do not compile this script into a directx11 compatible shader Lines following the Script declaration will be treated as HLSL code up until an End Script command. This command will be used signal to the ide and to the compiler that any following code will be treated as normal blitz/hardwired code. When you compile a Hybrid program now, if any Script command is found in it, the precompiler will be launched automatically. A window will appear, giving details of its progress and will close automatically is the precompilation of the shaders is a complete success. Please note that, unless the flag to not compile is given or if the shader profile is higher that the maximum version permitted for dx9, all shaders will be precompiled for both directx9 and directx11 automatically. If the HLSL compiler encounters any error in the HLSL code, it will indicate the problem in the precompiler log window and the compiler will not execute the code, returning you to the ide. For the moment, I have not yet activated the code that allows you to use the shader code in your Hybrid program (which will become the 'Recall' command). This will be coming shortly (yes, in September ;D). The aim of the exercise today is to see if the precompiler works. So, please check it out if you have time and let me know if there's any problems, or even if it works okay for you.  |
| ||
| Just re-uploaded a correction to this pre-release update. For those who are interested, once the shaders are compiled they are stored in a kind of archive (a continuous chunk of data that contains all the compiled shaders together), which is stored as one of the executed file's resources. Once run, the executable 'unarchives' this data when needed by 'splitting up' this data block into the respective shaders. I plan to use this same archiving method for storing files. Keep your eyes peeled for 'IncBin' and 'IncDir' commands that I plan to create. These commands will allow you to 'include' any file that will become part of the final .exe file. The idea is to be able to secure data files, by incorporating them all into the executable - if the user wishes to, of course. Stay tuned for this addition... |
| ||
| Another little addition. Since we can't decide on which is the best to use out of Script, Shader, ShaderScript and HLSL I have decided to use them all. If you so desire, Shader, ShaderScript and HLSL are valid commands and behave exactly in the same way as the Script command. You can even mix and match if you're feeling messy; starting with a Script command and ending with a End HLSL is valid for example. |
| ||
| These sound like really wonderful additions. That feature to include data in the executables, will certainly be welcomed by a large part of the Blitz community( I've seen someone looking for a solution like that on the forums only the other day). The aliased: That's really overkill imho, but hey if you can why not(you've got the power). But eh.. you left out HLSLShaderScript ;-), which would do the same thing as the different aliases, (if you wanna please the masses). ;-D I'll run some tests as soon as I can. |
| ||
| Looks great, I'm really a GLSL guy but this is tempting me to go over the the DX darkside! :P |
| ||
| Serious stuff ! It works here, I can compile hlsl_demo.hb. |
| ||
| Check out the demo with the deliberate error too. You should see the precompiler window with an error report. |
| ||
| Yup, ran both examples: working as intended and expected. :-) Only thing I noticed that the one with the error, was only exiting with the button, not the spacebar as was stated in the instructions. |
| ||
| Yes it works fine too. DirectX 9 Compiler error -> 'vs_man': entrypoint not found But with hlsl_demo.hb, It won't compile with flag 1 (Script vertex_shader("vs_main","vs_3_0",1)), only 0 or 2. I'm not sure if it should compile... It just return to the IDE with no error. Also, I had to deactivate the antivirus (Avast), because he puts ide.exe in quarantine with no information. |
| ||
| Right, I just had to share this early - I will give info later about new commands in this new prerelease but I'm busy for the moment. I've cracked it!! (hoorah :-D) Hlsl can now be included in the program script, it is precompiled into a workable shader at hybrid compile time, it is then bundled with any execuatble for any and all custom shaders (only vertex and pixel for the moment - others will follow). These same shaders can then be quickly 'recalled' at runtime for use on any entity. Please see included hlsl_demo.hb for a working example of three shaders (one vertex shader and two pixel shaders) that I quickly programmed. Hope you like... |
| ||
| I have some spare time now to explain some of the new stuff... The Scipt declaration command has now changed syntax. Its revised syntax is the following Script identifier(entry_function$,shader_type%,flags%) The identifier,entry_function$ and flags% parameters stay the same as explained in my first post on this thread, however I have replaced the shader_version$ with the shader_type% parameter. The following values are valid for this parameter.... 1 - Compile as a vertex shader; the vertex shader will be compiled once for directx 9 and for four different possible profiles in directx 11; a total of 5 versions shader code. The flags parameter of course still applies if you wish to disable compiling for a specific version of directx. 2 - Compile as a pixel shader - same as above, but for pixel shaders. 3 - Compile as a compute shader (not yet complete) 4 - Compile as a vertex shader (not yet complete) 5 - Compile as a vertex shader (not yet complete) 6 - Compile as a vertex shader (not yet complete) So that's it for the Script command. Once a script has been introduced into a hybrid program, the Hybrid compiler will recognise this and begin precompiling, according to the parameters given in the script command. If errors are found, a report will be made on the precompiler output window; if all is fine after the precompilation the output window will automatically close once done and proceed with the rest of the compilation. Recalling shaders Once run, a program can 'recall' a precompiled shader by using the identifier of the shader. There are currently two shader recall commands available... RecallVertexShader%(shader_name$) RecallPixelShader%(shader_name$) The shader_name parameter refers to the name given as an identifier in the Script command. If the shader is found, a handle to the shader will be returned by these two commands. Use RecallVertexShader only for vertex shaders and RecallPixelShader only for pixel shaders - mixing these will result in an error. Shader programming Two types of inputs exist for shaders... For vertex shaders, the first kind of inputs come from the object the shader is rendering; the object will send it the xyz values of each vertex, along with its vertex normal xyz values, vertex colour and eventual texture mapping coordinates. The vertex shader is called for each vertex and is always called before the pixel shader. The vertex shader's principal job is to calculate the screen position of the pixel where a vertex lies, once the three points of a triangle from the rendered object's triangle list have been calculated, the renderer will call the pixel shader for every pixel between these three points. However, you can program a vertex shader to do much more than that if you so wish, such as lighting or instancing calcuations. So, for every time that the vertex shader is called, these input values change, depending on the object being rendered. However, during the render cycle of an object, the second type of inputs can be used as global variables. These variables are actually called 'constants', as they do not change not matter how many times the shader is called for the object being rendered. For a vertex shader, three constants that are typically present are the world, view and projection matrices. These matrices hold the information needed for position, rotation and scalar values combined of the object in question, the camera viewing it, and the render viewport. Combining these matrices along with the current vertex position within the vertex shader in a matrix multiplication calculation will result in the pixel coordinates. Both vertex and pixel shaders are very configurable, but it is very important to remember thier role. Vertex shaders work in turn on each vertex of a mesh, pixel shaders work on each pixel of a triangle calulated by the vertex shader for each triangle of the mesh's triangle list (if that makes sense ;D). So, it is important that the vertex shader output has EXACTLY the same form and order as the pixel shader input. Apart from the input passed on from the vertex shaders, pixel shaders also have constants. For pixel shaders, typical constants are material information (ambient,diffuse & specualar colour) and lighting for any lights present in the rendered scene, however the constants can repesent whatever the user wishes depending on what he/she wishes to calculate within the pixel shader. The output and the final goal of the pixel shader is ALWAYS a colour and alpha value of the pixel; this being a four floating point value array in the order of RGBA, values range from 0 to 1. So, you can see that to really bring a shader to life, you need to use constants at some point. In Hybrid, you can configure shader constants by using the AddShaderConstant and the ValidateConstants commands. These commands should be used before rendering with the said shader in order to get correct results. The purpose of the AddShaderConstant is to notify Hardwired of the detail of the constants for a shader. The command is used to pass info about each constant individually, and in the same order as in the original shader script. Once the complete list of the constants has been made with this command use the ValidateConstants to inform Hardwired you have finished configuring the shader. The shader will then be ready for use. Please note that some shaders do not necessarily need to use constants, the necessity is at the descretion of the person programming it. See, for example, my sample hlsl_demo.hb. You will notice that only the vertex shader has has constants defined for it. This is because for the pixel shader I programmed there was no need for a constant. The syntax of the AddShaderConstant command is the following AddShaderConstant(shader%,constant$,type%,flags%,linked_object%,pad_it%,slot%) Parameter details shader - Refers to the shader handle returned by a recall function constant - The name of the shader constant (given in the shader script), this is case sensitive; watch your typing. type - The type of constant, this value indicates to hardwired the nature and size of the constant being defined , the following descibes each value... Manually programmed constants 1 - A four-byte floating point value 2 - Two four-byte floating point values 3 - Three four-byte floating point values 4 - Four four-byte floating point values 5= - A four-byte unsigned integer value 6 - Two four-byte unsigned integer values 7 - Three four-byte unsigned integer values 8 - Four four-byte unsigned integer values 9 - A four-byte signed integer value 10, - Two four-byte signed integer values 11, - Three four-byte signed integer values 12, - Four four-byte signed integer values 13, - A four-byte boolean value Automatically programmed constants 14, - A programmable matrix value (16 floating point values(4 bytes)=64 bytes in size) 15, - The world matrix value (16 floating point values(4 bytes)=64 bytes in size) 16, - The projection matrix value (16 floating point values(4 bytes)=64 bytes in size) 17, - The view matrix value (16 floating point values(4 bytes)=64 bytes in size) 18, - The world projection matrix value (16 floating point values(4 bytes)=64 bytes in size) 19 - The world view matrix value (16 floating point values(4 bytes)=64 bytes in size) 20 - The view projection matrix value (16 floating point values(4 bytes)=64 bytes in size) 21 - The world view projection value (16 floating point values(4 bytes)=64 bytes in size) 22 - A texture matrix value (16 floating point values(4 bytes)=64 bytes in size) 23 - A light matrix value (16 floating point values(4 bytes)=64 bytes in size) - Represents the closest light to the object defined in the linked object parameter 24 - A light matrix value (16 floating point values(4 bytes)=64 bytes in size) - Represents the second closest light to the object defined in the linked object parameter 25 - A light matrix value (16 floating point values(4 bytes)=64 bytes in size) - Represents the third closest light to the object defined in the linked object parameter 26 - A light matrix value (16 floating point values(4 bytes)=64 bytes in size) - Represents the fourth closest light to the object defined in the linked object parameter 27 - A light matrix value (16 floating point values(4 bytes)=64 bytes in size) - Represents the fifth closest light to the object defined in the linked object parameter 28 - A light matrix value (16 floating point values(4 bytes)=64 bytes in size) - Represents the sixth closest light to the object defined in the linked object parameter 29 - A light matrix value (16 floating point values(4 bytes)=64 bytes in size) - Represents the seventh closest light to the object defined in the linked object parameter 30 - A light matrix value (16 floating point values(4 bytes)=64 bytes in size) - Represents the eighth closest light to the object defined in the linked object parameter If a constant is defined as an automatically programmed constant, Hybrid will automatically take care of updating the constant when needed. For example, if you set a constant to a type n°15 (the world matrix), Hardwired will automatically set the relevant constant to the rendered entity's position, rotation and scalar values. flags The flag parameter is used to signal hardwired to further 'treat' the value before setting the constant. The following values are valid for the flag parameter 0 - Value will not be treated in any way and will be preserved as-is 1 - Transpose a matrix, if constant is not a matrix nothing will be done 2 - Invert a matrix, if constant is not a matrix nothing will be done 4 - Normalize a vector, if constant is not a vector nothing will be done Flags 1 and 2 can be or'ed is needed to transpose AND invert a matrix. linked_object% Used to tell hardwired which object is used as reference for the constant. For example if you use the type 14 (programmable matrix) and set the linked object to the handle of an entity (not necessarily the entity the shader is linked to), Hardwired will automatically set the constant to that entity's matrix (containing of course the position, rotation and scalar for that entity). pad_it - Set to true of false. Shader programming has certain rules you have to adhere to, in order to able to correctly program a gfx adapter. One of these is to remmber that shaders use 'registers' to hold all varibles. Registers are sixteen bytes in length each, so if for example a float (that only takes up four bytes) is used, the remaining twelve bytes can be left 'unused' by the shader if 'shader packing' is not used. Setting this parameter to true will indicate that the constant should be 'padded out' so that if the constant lies below the 16-byte count any remainder will be taken into account so that all constants recorded in hardwired remain perfectly aligned with the shader. Set to false if your shader uses some form of constant packing. slot - Registers can be grouped into 'slots' for faster access. Grouping constants into slots can improve performance, as when you update a constant, all other constants that belong to the same slot will be updated at the same time. An example, here is part of one of my pixel shaders...
cbuffer matrices : register(b0)
{
float4x4 WorldMatrix;
float4x4 ViewITMatrix;
float4x4 WorldViewMatrix;
float4x4 WorldViewITMatrix;
float4x4 TextureMatrix[8];
}
cbuffer lights : register(b1)
{
float4 LightAmbient[8];
float4 LightDiffuse[8];
float4 LightSpecular[8];
float3 LightPos[8];
}
The register b0 refers to slot number 0, b1 for slot number 1, and so on.... This all seems very compilcated but once you get the hang of it, it is quite simple and logical. In any case, once you have set-up a shader you can just let it do it's wonderful work and will not need to worry about redifing the constants. ValidateConstants(shader%) Use this command when all constant declarations have been made, this will validate the shader and make it operable. That's all for today, after all that typing I've got writer's cramp. Have fun.... Ps. for more fun, try replacing the second pixel shader in the sample code with...
float4 ps_main(VS_OUTPUT Input) : SV_TARGET
{
float y2=Input.position.y;
int y3=y2/8.0f;
if ((y2-(y3*8))<4)
{
return float4(0.0f,0.0f,0.0f,0.0f);
}
return float4(0.0f,1.0f,0.0f,1.0f);
}
End Script
I will give more info on shader constant programming when I can, tomorrow I hope (if time)... :-D |
| ||
Interesting ! Had to enable the use of directx 11 to get it work. So far i've been able to texture the cube with pixel shader... Now trying to get good lighting. HLSL is quite complicated but it's really interesting. |
| ||
| Nice one, if you feel like it (or anyone for that matter), please feel free to share any hlsl code on this thread. I am very interested in what shaders can do (which is a hell of a lot of different things). Now that I have the basics of the hlsl sytem covered, we'll really be able to have some fun. ;D |
| ||
| Hi Ploppy. Here is an example of a vertex shader that moves vertices of a mesh and a simple texturing pixel shader.  Click here for full size image I'm not sure if a vertex shader is designed for that but that was just a test and it turned out in something really amazing compared to native Blitz3D. I'm able to move 513*513=263169 vertices per frame on a single mesh with more than 500k triangles, and running at 1700 fps ! It's a bit nasty I guess, there are cracks in the mesh but the GPU power is something we could really use :) I hope we can communicate (passing variables) beetween program and shaders, or even use the GPU for calculation ! I can't wait your tutorial to go further :D Something I've notice is that if the camera doesn't move, and if a mesh with a shader doesn't move too, the shader isn't updated. In my example I must turn the mesh to make it updating if we don't move the camera. Also the Text command doesn't work ? So I used GUI to display FPS. Here is the example (you need a texture, "crate.png" in my example), I hope it works (change the "segments" variable, but don't go too far or it will take ages to load !) : You really did an awesome work to include shaders this way ! Hardwired/Hybrid starts to be usable for what it was designed from now. Time to learn HLSL for us ^^ |
| ||
| Smashing stuff, Flanker. Thanks for that, I'm really impressed by your rapidity and I'm happy it's working for you. Text, for the moment, still doesn't work in dx11 mode I'm afraid. I will sort out the little shader update problem. Still more shader constant manipulation commands to come. So far, I have explained the automatic constants; for manually modifiable constants I will be adding commands so that you can directly change these global variables. |
| ||
| I found a link with good tutorials about directx11 and shaders, basically I'm just trying to adapt the code, learning the basis of HLSL at the same time : http://www.rastertek.com/tutdx11.html In fact i'm working on a game project on my spare time and I love Blitz3D synthax but there is too much limitations with textures and meshes nowaday, even fastlibs is outdated, so I'm really interested by hardwired/hybrid and now HLSL :D Thanks for your work. Here is a per-pixel diffuse lighting shader with texture example, better than Blitz3D directionnal lighting :  You can play with light parameters in the pixel shader. The code to update normals according to light direction is in the vertex shader. A texture is still needed. I don't know why but the code affects pixels opacity, so I had to force them to 1 (color.a = 1;). EDIT: I found an issue about the screen aspect ratio. The width changes slowly with time. After 5 minutes everything is distorted on X (screen width) axis. It doesn't seem to be linked with shaders or dx11 especially. See this IMAGE. |
| ||
| You really are rapid, Flanker. Thanks for that. I too use the rastertek tutorials as one of my references, there really is a clear step-by-step way of teaching in these tutorials. Keep up the good work, it seems you are on a roll. It shows you understand hlsl pretty well, which is great. Others will not necessarily be able to use it so quickly, as it is very different from the blitz language. So anything you post could be beneficial for users to use as examples. |
| ||
| A new update has been released for the hlsl module. Continuing from the previous explaination of constants programming.... Manually programming constants If, when declaring your constants with the AddShaderConstant command, you choose a constant type with a manual update behaviour (see type list in the post #11 of this thread) hardwired will not manage the values automatically. It will be up to the user to update the values to manner he/she see fit in order to configure certain parameters that may be necessary for a shader to operate. The AddShaderConstant command is actually a function - ie. it returns a value. For automatically updated constant types, the value returned by this function was not really needed once set up, since Hardwired takes care of the rest. However, for manually updated constants, the value returned is a unique identifier to a constant's handle. The handle needs to be held in a variable for later use in the initialisation of a shader or in the render loop of a program. I have now updated hlsl_demo.hb to show a working example of both automatically and manually updated constants. You will remark that the constants "worldMatrix", "viewMatrix" and "projectionMatrix" remain automatic. However, I have included two new constants, one for the vertex shader, and one for the first pixel shader - these two constants are named "add_y" and "color". You will notice that the result for declaration for these two constants is saved in two variables, addy and colo. Please note also that for the declaration of the add_y constant that I set the pad_it parameter to true (the default is false). The reason for this is that the constant here being declared is a four-byte floating point value. However, do not forget that due to the way a gfx adapter works, it only deal with 16-bit registers. In order that the 4-byte constant complies with the 16-byte rule, setting the pad_it parameter will inform hardwired to make up for the other unused 12 bytes of the register. Failure to do so will result in a non-aligned constant buffer and will result in the program crahsing. Programming your constants correctly is very important. addy=AddShaderConstant(vs,"add_y",1,0,0,True) colo=AddShaderConstant(ps,"color",4) Modifing manually updatable constants Some new commands are now available in Hybrid/Hardwired in order giving you the ability to manually update constants, these are the following... SetBoolConstant(shader_constant_handle%,value%) - Will set a boolean constant to the value given in parameter 'value' SetIntConstant(shader_constant_handle%,value%) - Will set a integer constant to the value given in parameter 'value' SetInt2Constant(shader_constant_handle%,value%,value2%) - Will set an int constant containing two elements to the values given in parameter 'value' and 'value2' SetInt3Constant(shader_constant_handle%,value%,value2%,value3%) - Will set an int constant containing three elements to the values given in parameter 'value', 'value2' and 'value3' SetInt4Constant(shader_constant_handle%,value%,value2%,value3%,value4%) - Will set an int constant containing four elements to the values given in parameter 'value', 'value2', 'value3' and 'value4' SetFloatConstant(shader_constant_handle%,float_value#) - Will set a float constant to the value given in parameter 'value' SetVector2Constant(shader_constant_handle%,x#,y#) - Will set a float constant containing two elements to the values given in parameter 'value' and 'value2' SetVector3Constant(shader_constant_handle%,x#,y#,z#) - Will set a float constant containing three elements to the values given in parameter 'value', 'value2' and 'value3' SetVector4Constant(shader_constant_handle%,x#,y#,z#,w#) - Will set a floatconstant containing four elements to the values given in parameter 'value', 'value2', 'value3' and 'value4' SetUnsignedIntConstant(shader_constant_handle%,value%) - Will set a unsigned integer constant to the value given in parameter 'value' SetUnsignedInt2Constant(shader_constant_handle%,value%,value2%) - Will set an unsigned integer constant containing two elements to the values given in parameter 'value' and 'value2' SetUnsignedInt3Constant(shader_constant_handle%,value%,value2%,value3%) - Will set an unsigned integer constant containing three elements to the values given in parameter 'value', 'value2' and 'value3' SetUnsignedInt4Constant(shader_constant_handle%,value%,value2%,value3%,value4%) - Will set an unsigned integer constant containing four elements to the values given in parameter 'value', 'value2', 'value3' and 'value4' SetMatrixConstant(shader_constant_handle%,matrix%) - Will set a matrixconstant to the value given in parameter 'matrix'. Use the matrix commands (described in a previous thread) in order to manipulate a matrix for your needs In the little sample hlsl_demo.hb, you can see that I have used the commands 'SetFloatConstant' to manually change the 'add_y' constant and 'SetVector4Constant ' to manually change the 4 floating point elements of the 'color' constant. Doing this within the render loop has given me the ability to demonstrate that the constants here change the y position on the screen and change the output color to a random color. A shader can of course be much more sophisticated than this - I decided to keep this demo simple so it's easy to understand, and that way it didn't take me long to create (which is a good thing too). Enjoy, more tomorrow.... @Flanker - I added your two examples from the above posts to the archive, in hlsl_demo2.hb and hlsl_demo3.hb, as they are definatly interesting and demonstrate shader use very well. I hope that's okay with you.... :-D |
| ||
| Nice one with manual constants. Wich thread describes the matrix commands ? I can't find it. And yes of course you can put my examples along with Hybrid if they worth it. I also noticed that when using dx11, hybrid meshes command are a lot more faster, not as fast as gpu but a lot faster than b3d. Probably because graphics are fully handled by gpu so cpu can work faster or something like that. I like that :) |
| ||
| Matrix commands listed in this old post |
| ||
| This is really great work Ploppy and thank you for the example Flanker. It would be nice though to have a HLSL to Hardwired/B3D script format generator. |
| ||
| Follow up question: so far the shader examples are for entities, how do you apply shaders to the whole screen aka post-process filters? camera or screenbuffer? |
| ||
| Hi RustyKristi, I don't quite know - shaders are a relatively new thing to me, but I am doing lots of research to learn more about all this. However, I do not think that shaders directly treat a screen, so to speak. Vertex shaders, as the name suggests are strictly for vertices and pixel shaders are used for treating the pixels coming from the output of vertex shaders; so these two types of shaders are dependant on meshes/triangles. There are other kinds of shaders; compute, geometry, hull and domain. I do plan to integrate full management of these kind of shaders as well - please note that these shader types are for dx11 and beyond, they are not compatible with dx9. They deal with tesselation techniques and displacement mapping, amongst other things. Again, mainly reliant on meshes. I think what you are referring to 'post process filters' are quite possibly done using a simple shader trick. The idea I am supposing is that the whole 3d scene in it's entireity is rendered to a texture, and not directly to the screen backbuffer. This texture is then linked to a simple two-traingle entity with the same dimensions of the output screen/viewport. This entity is then rendered. If a custom shader is used with this method, you can apply all sorts of things to the whole image (blur, emboss, brighten, fade, anything...) Another 3d technique that is often used is of course a stencil. I have not yet implemented stencils into Hardwired, but I do plan on doing so. Multisampling techiniques and multipass shader techniques will also follow. @Flanker - I received a message from paypal earlier on your behalf. Just to say thankyou for your generous donation, I really do appreciate :-D |
| ||
| I'm starting to bring all the modules back in, bit by bit. Should soon release on the worklog. In the meantime most things work as expected. Some new stuff for today.... AddShaderConstantArray%(shader%,constant$,size%,type%,flags%=0,linked_object%=0,pad_it%=1,slot%=0) If you have any array in a shader constant list, you can declare them with this useful command. Instead of having to declare each element of the constant in question, this command will declare the constant by the number of elements provided in the parameter size. The returned value is the handle for the whole array. Elements of the array can be retrieved by the function below. A typical array in either c++ or HLSL has the variable identifier directly followed by the array size, surrounded by square brackets.... float colour[5]; --- this would initialize an array of 5 floating point values, for example, much like a blitz equivalent Dim colour(5). FindConstantElement%(array%,element_number%) This function will return the handle of an individual element found in a constant array. The array parameter is the array handle, returned from a AddShaderConstantArray function. The element number parameter has to be in the range of 1 up to and including the size of the array. The command FindConstantElement can be used at any moment for any amount of times as long as the shader exists; whether it is during initialization of your program or inside a main loop. Including binary files into your executbles INCBIN filename$ - With this new linker directive, you can indicate your intention to bundle files into your compiled executable. If the given file exists the linker will automatically include the file when compiling. RecallFile%(filename$) - This command will recall a file previously included by the INCBIN command. If the filename provided (not case-sensitive) does not exist within the resident archive, the returned value will be 0. The filename must be exactly the same path provided in the INCBIN command or else it will not be found. If the file is found a blitz bank will be returned, containing the file in question. Please see hlsl_demo2.hb for an example, here you will see that the stone texture is 'saved' with INCBIN and recalled during runtime using RecallFile. The texture is then 'loaded' as a texture using the LoadTextureFromBank. Try compiling this file to an executable instead of compiling directly. Run the exe file, you should have the same result and will no longer need the texture file - this compiled executable should be totally independant of the texture file in question and can be run in any folder without any additional files. PLEASE NOTE: * Although the bank returned by RecallFile is 100% compatible with LoadTextureFromBank, it isn't quite yet compatible with other bank commands. I'm still working on that but I'll solve this little problem for 100% compatibility with bank related functions... * I am aware that some of the samples render lighting a bit strangely, (such as the maze sample). This is not a bug, I am currently redesigning the in-built shader that renders for dx11 and, when in HWShader mode, for dx9. The vertex and pixel shader I am in the process of creating is designed to 'emulate' the directx9 fixed-function pipeline. This is very complex, so it takes time, but I'm getting there.... |
| ||
| The most feared for me, are the shaders, I mean I try to learn, because my language is not English, so I have to do double duty. But maybe I try to encourage learning. |
| ||
| It is worth it Yue, but I'm trying my best to simplify things. Believe me, the hard part is programming directx and linking it all together without it crashing. In any case, I hope that this powerful HLSL module will inspire users to publish thier own shaders on the forum. If there is enough examples available of different shader techniques, you will be able to take inspiration from there. The more people that share thier Hlsl scripts, the better - even if they are simple they are still instructive. It's early days, but I hope there are a few courageous ones out there :-) |
| ||
| Ah I was wondering if it could be possible to pass an array then you did it :) Seems that we are limited to 4084 elements by shader array (4096-12 ?). Here is another example to move vertices with realtime control thanks to shader array. I think it is more stable to use the input values instead of the output. This example creates a plane grid with a shader wich move vertices at a speed controled by deltatime so we should have the same speed at any fps. The plane grid is duplicated as instance several times to raise the number of triangles (you can modify the "dimension" variable to duplicate more, but be careful !). I went up to 76.880.000 moving triangles at 4fps ^^ Ploppy, in the vertex shader, is there a way to know at wich vertex index we are ? In this example I must use vertex position to know but that's not very versatile. |
| ||
| What I suppose you could do is cheat a little by using the second texture coordinate set, assuming you do not use it already for coordinate purposes. Not many programs require the second coord set but it is part of the vertex structure, and in Blitz3d/Hybrid you can of course program that to whatever you want with the VertexTexCoord command. For example VertexTexCoords surface,index,index,0,0,1 This would set the x coordinate to the vertex number being programmed on the second coordinate set. In your HLSL script, you could recover this info with a line such as float vertex_number=tc2.x; |
| ||
| I have failed to mention that there is a restriction to my shader management system. Vertex shaders have the ability to interpret a mesh in any way that a user wishes as it's input. You can, for example, just store/send posionional info on each vertex and nothing else. However, for the moment my engine does not give the ability to customize a vertex structure. I will work on that part in order to increase flexibility. In the meantime the structure for vertices is strictly the following... struct VS_INPUT
{
float3 position : POSITION;//relates to the vertex poition xyz
float3 normal : NORMAL;//normal xyz
float4 color : COLOR0;//rgba float(0 to 1)
float2 tc : TEXCOORD0;//x,y
float2 tc2 : TEXCOORD1;//x,y
float4 instance_m0 : TEXCOORD2;//xyzw
float4 instance_m1 : TEXCOORD3;
float4 instance_m2 : TEXCOORD4;
float4 instance_m3 : TEXCOORD5;
float4 Color2 : COLOR1;
};Please note that the constants 'instance_m1', 'instance_m2', 'instance_m3' and 'Color2' are used for instancing. I'll explain about instancing programming at a later date. |
| ||
| New worklog entry - Previously deactivated modules are being brought back into play.... |
| ||
| Second worklog entry - Small explaination of some other new functions.... |
| ||
| Hey Ploppy, I was wondering if you are also planning to have the shader code read/compile as external files? and I'm also getting "Expecting EOF" error when I create 64 exes with the demo code. thanks |
| ||
| Hi Rusty, The 64-bit module is on standby, sorry I still have that to convert. As for shaders, external loading and compiling is already part of hardwired... CreatePixelShader%(operation$,file$,entry_point$,version$):"dCreatePixelShader" FreePixelShader(pixel_shader%) CreateVertexShader%(operation$,file$,entry_point$,version$) FreeVertexShader(vertex_shader%) |
| ||
| Awesome, thanks obviously I missed those as I can only see your old version online docs of hardwired from previous post. At this point, is it safe to say Hybrid already got the default Blitz3D functionalities? meaning can we port existing code or what not or is it still a work in progress? |
| ||
| The B3d command set is not entirely covered yet. I would say that a good 80-90% is done for the moment. There still are some holes, but it's going in the right direction, I feel. |
| ||
| New worklog entry |
| ||
| good stuff :) question: what kind of protection is applied to the incbin files/folders? any compression, encryption or at least obfuscation? otherwise it would be quite simple to extract them from the exe...i guess not for the moment, but might be worth a thought later on... btw: i never wanted to learn shader languages because i would have to do more c++ (which i hate personally ^^) to make use if 'em etc, but this project might change my mind, it just looks more clear and easier to work with now that i see it embedded in blitz! :D please make this happen! |
| ||
| Hi Ojay. Yes, I have thought about both encryption and compression. I haven't done so yet, but it does seem like the next logical step for my program. I'm glad you're reconsidering learning hlsl. It resembles c++ a lot, but it isn't as vast as c++. I would like to construct a hlsl tutorial page, perhaps online, but for the moment my time is limited. By the way, I agree with you about hating c++; I don't like it either, but for me it is a necessary evil ;-) |
| ||
| Here's a little update for the in-built shaders i'm working on - my shaders are becoming very large and are almost complete. The default shaders are the ones that are used when in dx11 mode when not using a user defined shader. You can also use these default shaders in dx9 mode if you use the HWShaders True command. You will notice quite an improvement over the previous release, especially concerning lighting. I have almost finished this part, I have a few tweaks left to make on specular lighting and then it will have exactly the same functionality as the original directx9 fixed function pipeline and give the same result which is of course what I am aiming for. I will of course be expanding upon all of these these functionalites afterwards so as to include some in-built shader effects into hardwired. It's all taking shape... |
| ||
| Great update Ploppy! Just curious about this so another question, will the other wrapper still works and hook up without any hitches in Hardwired, say like Physics Wrappers, DLLs etc. |
| ||
| I think that very much depends. All dll's are compatible as far as calling them is concerned. However it will depend on what the functions in those dll's do. For example, if it is a sound library, it will have no conflict whatsoever with directx, or with hardwired. However, if we are talking about a wrapper that manipulates a 3d entity or mesh that worked with Blitz3d for example, the chances are that it will not work. This is because the structure of a mesh manipulated by hardwired is not the same as a classic mesh structure used in B3D. Physics engines may possibly work, if again they do not directly manipulate entities or meshes. Texture manipulations will have to respect the same principles. |
| ||
| Ok I see. so far I'm getting 'userlib not found' errors on a couple of physics wrappers I've tried (Tokamak, etc) during runtime. For exe 32bit, it compiles ok but it crashes when launched. I sure do wish they can be eventually useful and work along with the new powerful DX9 and 11 capabilities :`( |
| ||
| Hey Ploppy, I just noticed that you already got some physics functions built-in for Hybrid? that's awesome!!! I guess there's no need for them physics wrappers anymore ;-) Now to try other libs out there.. |
| ||
| Yes, I linked hardwired to the Physx library a while ago. For the moment, I have added just a little of the libary's capabilities but I do not plan to stop there and I will be working much more on it. I also plan to include a fur/hair physics engine which will look really cool - but I am a little stuck on which to choose between Hairworks and TressFx. They both look cool... The choice is very hard to make. The new tomb raider that's coming out in november looks really good too. I may have to stop developing hardwired for a week or two in order to play it :-) |
| ||
| For the moment, I have added just a little of the libary's capabilities but I do not plan to stop there and I will be working much more on it. Nice, this looks really promising! The choice is very hard to make. The new tomb raider that's coming out in november looks really good too. I may have to stop developing hardwired for a week or two in order to play it :-) good for you! this is just right. A little "ME" time is really what you need every now and then to get you out of stress. :-) whoa! they both look good!! umm, but since you already got PhysX going I suggest Hairworks, but that's just me ;-) Like they say, go with your gut! Or you can do both and with the other eventually, by UserLibs/DLL? keep it up! |
| ||
| Second worklog entry - New powerful text related functions are now available |
| ||
| New worklog entry - Terrains in hybrid are now dynamic LOD terrains like in B3D. I am now onto working on the splatting routines for terrains.... should be good, further update soon.... |
| ||
| Hehehe, it's getting to be a pretty massive working machine. BTW, for continuity and stability(dunno if matters really in this case) but as NVIDIA PhysX has been incorporated, I'd go for the 'Hairworks' option also. |
| ||
| Thanks for the update Ploppy, those are nice additions! |
| ||
| A little off the subject, but check out this site for a really good example of what shaders are capable of (this is not at all my work, but I found this a great site :-D ). |
| ||
| you probably do know it, but just in case: https://www.shadertoy.com ;) (regularily crashes my browser and is GLSL only, but nice ref anyway ^^) |
| ||
Hardwired is now two years old since I first issued a post on this forum. Things have come a long way since then, and I have learnt a lot - probably more than I can absorb or deserve :-) But in any case, hardwired has since become rather large, I have eradicated many bugs (and have created some in the process as well, goes without saying), and Hardwired has even given birth to its illigitimate sprog Hybrid (hardwired had been seeing B3D behind BlitzMax's back for some time, a little accident was somehow inevitable!). Hardwired has also adopted much of the original B3D command set, and of course I'm still working on the B+ command set too. Shader manipulation, both in dx9 and dx11 is really starting to take shape and become fast and powerful. Even some basic physx functions are available, to be expaaaanded upon. Still big plans left, and much left to conquer. Let's see what I will have added to the feature list for the third birthday.... All the best to everyone and thanks for all the support.... |
| ||
| Heeey Congrats Ploppy! Great efforts and awesome work as always! :D |
| ||
| New little update for you. RenderToTexture now works, see test1.hb for a demo. RenderToTexture texture% - Instructs hardwired to render all subsequent renderworld commands onto the texture chosen with the texture parameter. Please note that a renderable texture has to be created with a value 1024 as one its flags to inform HW that the texture is a render texture. RenderToScreen - Resets the render output to the default output window.        |
| ||
| Hardwired is now two years old since I first issued a post on this forum. Things have come a long way since then, and I have learnt a lot - probably more than I can absorb or deserve :-) But in any case, hardwired has since become rather large, I have eradicated many bugs (and have created some in the process as well, goes without saying), and Hardwired has even given birth to its illigitimate sprog Hybrid (hardwired had been seeing B3D behind BlitzMax's back for some time, a little accident was somehow inevitable!). Hardwired has also adopted much of the original B3D command set, and of course I'm still working on the B+ command set too. Shader manipulation, both in dx9 and dx11 is really starting to take shape and become fast and powerful. Even some basic physx functions are available, to be expaaaanded upon. Still big plans left, and much left to conquer. Let's see what I will have added to the feature list for the third birthday.... I admire their tenacity to keep this afloat, as mentioned in an entry previous, how difficult it is to keep everything together and make it work, always give me a pasasa pora here and watch how things go.I desire to continue with the same motivation as always. :) Birthday Cake hybrid. :)  |
| ||
| HAPPY BIRTHDAY HYBRID! AND THANK YOU PLOPPY! :D I hope to see sometime in the near future, a way to convert Hardwired code into HTML5 / WebGL! :D |
| ||
| Congrats and good luck, its very inspiring to see someone work so hard and achieve his goals. Oh BTW, PhysX, wow, :D! |
| ||
| Small correction made in this new update. Some people may have experienced keyboard related problems- this mainly concerns users that use a keyboard that does not use the standard american configuration. I have now reprogrammed the hardwired input system so it behaves like B3D and will use the same scancodes as the classic american keyboard layout. This configuration does not affect the system keyboard layout and is strictly local to the executed program. Post modified - it seems this update is not so good - still a few keyboard bugs , reverting to the old one, I will release a better version another day.... |
| ||
| [post deleted due to duplicated previous post after forum error] |
| ||
| Update from previous post - it works now :-D Keyboard should behave correctly as in B3D without changing system layout.... Small correction made in this new update. Some people may have experienced keyboard related problems- this mainly concerns users that use a keyboard that does not use the standard american configuration. I have now reprogrammed the hardwired input system so it behaves like B3D and will use the same scancodes as the classic american keyboard layout. This configuration does not affect the system keyboard layout and is strictly local to the executed program. |
| ||
| Hip-hip-hurray! Congrats Ploppy. We should throw a virtual Hardwired/Hybrid Celebration Party! |
| ||
| New worklog entry - New internet access functions are now available |
| ||
| Great news that you are taking this on. Currently I'm on the hunt(as you may have noticed) for a good UDP library for creating a multiplayer game, but none off the one's available for Blitz3d do a full flawless trick. Appears only BPPro(not the BPLite version) can do everything required, however it's no longer available fafaik. Important features are good syncing and host switching a la Quake3, so no one looses the game when the initiator(host) decides to go do something else. It's really annoying to find all solutions come with their own flaws and/or are unfinished. Pff. Hope you'll be able to build on the networking features so we can do what everybody does these days: create multiplayer games. But I believe it's a heck of job and science in it's own to get that going, perhaps possible to incorporate a 3rd party lib on this one? |
| ||
| New worklog entry - Additional internet access functions are now available |
| ||
| Hey Rick, yes I do wish to work on UDP stuff and FTP also. I did already work on a semi automatic TCP library in the past so I have some code I can use - just need to convert the rest. But I really would like an all-purpose internet library as part of hardwired - it'd be great to be able to control things this way. |
| ||
| Cool! That would solve lot of problems. |
| ||
| I had a really nice surprise today. Three years ago I wrote a little email to Jari, the author of escapii (a webcam oriented dll userlib), asking for some help on coding webcam functions. I received a reply today from Jari saying that his code has been released as open source. This is great for me, as using this code as a base I should be able to easily incorporate all of escapii's functionality into hardwired. Webcam functions will arrive sooner than I planned - great stuff, can't wait to be able to render webcam directly to a texture... |
| ||
| Another marvel on it's way. Spooky how things get together like this. Almost as if it had to be. As they would say in Ripley's Believe It Or Not: "Coincidence? I think not!" :-) |
| ||
| Probably not much use, given you're working from the source anyway (didn't know he'd released it!), but I did a BlitzMax wrapper some time ago: ESCAPI 2.0 Webcam/Image Capture Jari does have an interesting audio library, too, not sure if you need one at this point though! http://sol.gfxile.net/soloud/ |
| ||
| Yes, mate. I have already included escapi into my source now and it compiles perfectly without errors (after a little tweaking). So I am now in the process of linking it in to hardwired and creating the functions, it seems quite straightforward and Jari's code is nice 'n tidy so I should be able to get something up and running pretty quick and then I'll release. I will look into the sound library, I am still on the lookout but I haven't quite yet found the lib that suits my needs. Thanks for the tip. |
| ||
| OMG! IF YOU MAKE A STREAMING WEBCAM SERVER / CLIENT EXAMPLE WITH SOUND, I WILL HUG YOU BRO! :D |
| ||
| Hehehe, that sounds interesting indeed GF(I have some very cool ideas with that), but I guess we'll have to be patient, for not decided on a sound lib yet(not to mention the additional stuff that comes with that). |
| ||
| Hi Gf, yes I would definately like to be able to go that way - but I have still some way to go for that. Audio & mic access and some pretty heavy duty networking stuff - but the more I do, the more it all seems possible. I live in hope.... New worklog entry - Webcam access functions are now available!!! |
| ||
| New ftp access functions are now available!!! |
| ||
| Love to see so much being done here Ploppy. Sorry if I missed it above but have you added any integrated sound management like b3d or do users simply add their sound library of choice ? |
| ||
| No, not for the moment on Hybrid. If you wish to use sound I recommend you use hardwired. I will include a sound library but I'm actually mulling over which one to use, or if it's not too difficult I may de cide to program my own routines. I am currently working on the 64-bit version. |
| ||
| Although I haven't finished with my most recent internet module, and that is going relatively easily I'm happy to say, I have recently got a new inspiration on the 64-bit version front, so I'm going back to that for the moment. It always has been a good thing for me to pick things up from time to time and move onto other things when I get stuck, it helps unblock things and gives me time to mull problems over. The 64-bit version of Hybrid/Hardwired has been one of the hardest parts for me. Of course it is not entirely necessary to produce a 64-bit version, you can still do a LOT of things with the 32-bit version; but I really feel that it is due time to have a 64-bit version to bring things in line with modern systems. With 64-bit you can of course acceess the whole of the system memory, giving more power and potential. So anyway, since I started picking up this module again several days ago after my recent breath of inspiration I have made a good lot of progress. I have learnt quite a lot on the x64 processor architecture and its instructions, calling conventions and opcodes. It's all fascinating and difficult stuff (really going down to the core machine code here, guys), but I am now getting somewhere. So, I'm presently in the midst of converting the Hybrid compiler so it compiles for 64-bit as well as 32-bit. So the new registers and thier sizes have to be taken into account, I'm having fun with this. I have updated the instruction database to include the x64 definitions and some parts are now coding correctly, things have never looked so promising! I am dumping a lot of my compiler results instruction-by-instruction and comparing them to precompiled x64 code written by a assembler. If there's any differences, I work on them and little by little I'm ironing out the bugs. Hardwired, has already been written and converted to the 64-bit version, so that's ready to be used - all that's left is the compiler side of things, and of course, I have to get this 100% right. It's all looking really good, and from my point of view I have made a big leap forward in getting the x64 part completed. I have nothing yet to release, but I thought I'd share this info you just to let you know how things are going in general. If I'm lucky, I may be able to release the x64 version next week - once that's done that will be a great hurdle overcome. Since I began on my initial whim of a project two years ago, I never ever expected to come this far. Two years have since passed, and although there are many strings to tie up, I feel that hardwired has come very far since its beginnings. If hardwired carrys on going the way it is going, I could end up in anthother two years as a very good contender to some of the compilers already available. Would be great to see hardwired used in other people's projects. This of course would justify hardwired's existence and all my work. I just hope I get that far.... |
| ||
| That's really, really good news Ploppy! Hope you succeed in cracking this nut. Keeping fingers X-ed. |
| ||
| I also had another idea which I may or may not develop, but if I do this will come later. Since the compiler contains an assembler that creates the runtime code, I could develop upon this assembler so if you wished to you could include asm code directly in your script; similar to what I have already done with hlsl code. Just a thought, but it could add nicely to Hybrid's versatility. |
| ||
| Yep that indeed does open up even more possibilities for people with enough skills. I'm guessing that would really be appreciated by the advanced programmer. |
| ||
| Well done mate for sticking with it :) |
| ||
| Wow Ploppy, great to hear you still have the motivation to even work on this!! The inclusion of being able to do inline ASM would make Hybrid a contender with PureBASIC. Thanks for the great work, looking forward to the completed product. |
| ||
| well if you go down the ASM route, you might as well add precompiler definitions/macros/conditions! ;) are you actually keeping a plan or something on features you want to implement, or is it just a day-to-day "whatever im in the mood today" kinda situation? ^^ dont get me wrong, features are always great. but one can easily fall too deep into the rabbithole if you know what i mean! |
| ||
| Well, if you look back at all these threads you'll find Ploppy has indeed that kinda I-do-what-I-feel-like-when-I-feel-like system, which apparently has worked great for him so far.(Which reminds me to put this one in the updated FAQ, for it's not the first time asked. lol) Even though it's not how I personally would (or even could)handle things, that what works for one does not necessarily work well for another. It's his personal project so he can do whatever he feels like and to be honest it has gotten him pretty far I must say. Pretty, pretty far, so I assume he knows what he's doing. :-) |
| ||
| Hi, I'm not sure that I do know what I'm doing, but it's the best method that works for me. Since the beginning of my project, I have been basically challenging myself to see if I was able to do achieve certain things in programming. It seems I have much further than I would ever have anticipated, so that's all good stuff. I have never studied programming in depth at school/college, so I never exactly learnt a tried-and-tested approach at programming; I am sure that there are better and more structured methods than the one I use of course but I go with what I know. Anyway, my method is not exactly I-do-what-I-feel-like, but it is not far off. I do try to bring different modules together bit-by-bit, but sometimes I do get stuck with one, so I'll just leave it after a while trying and I'll come back to it at a later time. I'm still of course working on the 64-bit version at the moment, but I am making some good progress. I am now able to correctly compile an empty project. This sounds like no progress at all, but there are plenty of initialisation code before the main program and cleanup code after it. This is working fine now, so this really is good progress, meaning that I have basically cracked labelling, calling and relocation code; and this all in ASM code. I'll let you all know of course when I have something worth releasing. |
| ||
| dont worry, was not meant to criticize; not even questioning! just that im impressed about your...pertinacity (? is that a real word? ^^) but maybe that kind of unstructured process is what brought you that far...if you would have put all this on a to-do list at the beginning, you might have gotten up early on! so anyway, keep on rocking. this thread made it into my check-daily-bookmarks (because its actually worth following)! ;) cheers |
| ||
| No problem OJay, I didn't take it for critism at all. And quite honestly, even if it was, I could understand why I could be critisised - I do realise that my work method is a bit unorthadox (is that a real word too ;D), but it's the only one I have. I'm probably too old to change my way of going about things now anyway.... |
| ||
| Hi Ploppy, how would you assign a texture to a shader ? For example if I declare a texture in the pixel shader with "Texture2D diffuseTexture;", how can I assign a specific texture to it ? I tried several ways to assign a blitz3d LoadTexture handle but I can't get it to work. Should have a SetTextureConstant command or something like that maybe ? |
| ||
| Hi Flanker, offhand I can't completely remember because I haven't worked on that module for a while. But if I recall correctly, textures are automatically assigned to the shader resources by the renderer, depending on the mesh. If you assign a texture using the usual EntityTexture mesh,texture,0 for example the renderer will assign the texture in question to resource number 0. |
| ||
| Thanks for the answer it works ! Useful for multitexturing and normal mapping for example :) |
| ||
| Sorry, It seems to occur only If I compile just after a modification. |
| ||
| I am still of course working on the x64 version of Hybrid - it's taking longer than expected as there are many factors to resoect with the x64 code. But I am getting somewhere with it. At the same time I am eliminating some memory leaks that I hadn't dealt with. Perhaps the bug you encounter was something to do with these memory leaks. |
| ||
| Yes the performances are slightly different at each compilation. Instead of 8000 fps it can drop to 7000 :D 32 bits already runs well, and what you did with HLSL is amazing. But yes, 64 bits is probably the way to go for modern systems. The only real issue I see at the moment is using tabulation in the hybrid IDE. It messes up the code and makes things hard to work on a "big" project and even more to import a blitz3d project. But I guess it's not the hardest part lol just a matter of time. For now I play with HLSL but in the future I'll move my project to hardwired/hybrid. |
| ||
| I really hope we get to a point where something can successfully be created and/or published using hw/hb, in 32bit or 64bit mode. I would really get a kick out of that and to me it would make it all seem worth it. We'll see. I am quite confident but I know it will take some time to get it all together. |
| ||
| This post is mainly just to prove that both myself and hardwired are not dead. I am still working quite hardly on the x64 version of the compiler module. It is taking some time, but it is beginning to bear some fruit. So, to anyone that may be interested, I have uploaded a prerelease version of the Hybrid x64. For the moment, compiling code to x64 is very very limited. At this time, only single integer variables are working, maths should work on these variables. As for any commands/functions, as long as these are configured either by constants or by these integer variables some commands should work. So, as you can see, this is just for demonsration purposes, nothing else. For/Next loops do not currently work, but while/wend and repeat/until should do. If statements do not work. In the Hybrid IDE, remember that to compile in 64-bit mode, use the 'Run x64 program' in the menu, or alternatively use the F10 key on the keyboard. Please note that debug mode does not presently work in 64-bit mode, so disable this before compiling or else a crash is garanteed. An example program that should work fine in 64-bit mode Print "hi there" Waitkey or this one... Graphics3D 800,600,32,2 Color 0,0,50 Rect 0,0,200,200 Color 0,255,255 Print "45*23="+45*23 Print " " Print "Press [Esc] to quit" Repeat Flip Until KeyDown(1) With all these restrictions you can see that there is not presently much that can be done with the x64 version; so in some respects this really doesn't look like much progress at all....Wrong, a lot of progress has been made and in some ways the hard stuff has been overcome. To get this far means I have managed to recode the part of the compiler that creates correctly coded assembly, and that the correct calling convention has been respected for function calling. What is left to do now is just to recode the different types, which I am currenly working on. With a little luck, and spare time on my hands, I should have the x64 version cracked by the end of the year, I hope... Click here! |
| ||
| Works here on windows 8.1 64bits. I still play with Hybrid and HLSL to learn. Here is a shader adapted from this article : GPU Gems - Triplanar mapping It's a triplanar shader to texture any object with one texture projection per axis. I extended it to support 6 textures (one for positive axis, one for negative axis). No need for UV map, it can be very useful for terrain or complex objects. Also I tried to use mipmapping playing with SamplerState and SampleLevel but nothing seems to work for the moment, even with mipmapping flag for textures.  |
| ||
| even though i must say, 64bit is not really on my must-have list, its great seeing you progressing with it :) will this actually support 64bit double precision entity/vertex coordinates afterwards? that would make spacesims the major genre for hybrid i suppose! :D |
| ||
| Hi Ojay, Hybrid even in 32-bit does fully support both 64-bit integer and floating point types already. However, the architecture of graphics adapters (even the most modern ones to my knowledge) compute with registers of up to 32-bits in size. This is the case for both matrices and for vertex descriptions, which is of course processed by the shaders. In order to make use of 64-bit variables you would have to convert them to 32-bit after any value change; resulting in a loss of precision in the process. That's just the way it is with the graphics adapter architecture. I would like to be able to program shaders in 64-bit precision too, but for the moment the manufacturers do not see the need, I guess. The 64-bit version of Hybrid I am currently working on is aimed at 64-bit memory access, which is another issue. However, in 32-bit or 64-bit mode you will only ever have a real 32-bit precision mesh; or at least with the current technologies available this is the case. Flanker, I love the shader - great to see, and I might inspire myself with this shader, since I still wish to integrate a texture splatting routine into terrains. Thanks for that, I am personally very interested to see any shader work in Hybrid; which is great for compatibility tests. Keep 'em coming... :D |
| ||
| Doubtful but will you be adding threads? |
| ||
| Actually it is already part of my 'compiler overhaul' plan. I think it will happen, in both x86 and x64 mode. |
| ||
| yeah, i thought about that too. i guess the rendering part would've still to be camera oriented...so huge worlds would still require bit of work. but at least it will be more convenient to work with longs internally... :) |
| ||
| I see what you mean. You could of course use 64 bit precision to represent certain parts or all of a 'world'. Data recorded could be vertices or coordinates or even rotational data, if needs be. This data could then be converted in realtime to 32-bit precision at rendertime, using the render camera as point (0,0,0),therefore virtually shifting all coords in order to consrve maximum precision in the conversion before sending the data to the shaders. Just a thought of course. I'm sure there are other methods too. |
| ||
| Thanks for that, I am personally very interested to see any shader work in Hybrid; which is great for compatibility tests. Keep 'em coming... :D I'm working on an ocean shader based on Gerstner waves right now. I really like how easy it is to develop shaders in Hybrid !  Video in motion : http://youtu.be/GCpSjzMhfl4 |
| ||
| Impressive. I didn't realize this was taken using hybrid right away, I thought this was a demo from your original gerstner source. I'm quite proud it is working so well for you. Thumbs up for some great shader work, flanker. |
| ||
| Flanker, can you make TOTALLY CRYSTAL CLEAR water & add a small source example? Thank you! Ploppy :: I would pay a FAIR price to BUY Hardwired if it could output the final source into total WebGL! Excellent work so far guys! Keep it up & Happy Christmas / Merry Holidays! :) ~GW |
| ||
| Ploppy, then I would say thumbs up for the great HLSL implementation ^^ Guy Fawkes, let me comment the source and I'll post an example, but it won't be transparent for the moment, it will need a lot more shader work. The example above can be done in pure blitz3d. You can find a great article about gerstner waves here : http://http.developer.nvidia.com/GPUGems/gpugems_ch01.html And a start for an HLSL shader here : http://www.gamedev.net/topic/648388-gerstner-wave-function-hlsl/ EDIT, here it is, with some comments : For the texture you can use this one wich is pretty nice : waterHi I run this example at 276 fps on Radeon HD9750. |
| ||
| Hi GF, I cannot even dream of doing what you requested I'm afraid. I am still working on the directx version since two years, and I haven't even finished that! If I decided to branch out into webgl compiling I would have to allow for opengl, glsl and javascript coding which is a huge undertaking, as you could imagine. This would likely add years to my already very ambitious project. I program hardwired in my own spare time, I do not do this for a living and I work solo. So all this takes time. However, have you checked out MonkeyX? It seems to me that this may well be what you're looking for... |
| ||
| This water stuff is looking really great. Can kick FastExtend out lol, if.. I can get Hybrid to work on Win10 Pro x64, for I'm currently getting a window with the title: "BlitzBasic" and a message: "Compiler environment error: Unable to open runtime.dll". -Is it perhaps possible that I need to reinstall(again) DX7/DX9 in Win10? Or is this an error that is related to something else? -In Hardwired I'm guessing it isn't working yet right? |
| ||
| Hi Rick, try this it may work, I have also improved the debugger for the x64 version. Shouldn't entirely work, but improved. Unicode types now display for the 32-bit mode in the debugger too. Example a$$=UniChr(9775) Stop This example code will set the variable a$$ to a yinyang symbol. |
| ||
| It is possible that you do need to reinstall directx if you install win10. I know that with 7 and 8 this is the case. Although dx9 was recognised, the last revision of this version was not included with windows by default. It may already be present in win10 - I honestly don't know for I haven't had the guts to try win10. |
| ||
| Title: "BlitzBasic" and a message: "Compiler environment error: Error in userlib 'hardwired.decls'-duplicate identifier", so I guess Hardwired conflicts with one of the other dll's I have in the userlib folder(many). Also Hybrid made Win10 BSOD, you know the standard ;( without any 0x0000.. code. Very handy. Now I'd need to go into logs to figure out what happened? Great new Win8.x /10 BSOD's feature lol. |
| ||
| Update1: 0xc0000005 - apparently very generic, non-informative error. What's new huh.. Question: -Anybody here tried HW/HB on Win10 recently(after the last major Win10 update that's is)? Update2: removed all dll/decls from userlibs, now Hardwired doesn't have any conflicts(and I found the conflicting decls; was an old dx9 addition with same dx prefix I installed from a backup), however the water example is for Hybrid only I believe, so can't run that yet. Pity would have been fun seeing it in action. And: can't install "DirectX 9.0c End-User Runtime". It simply refuses, only will install on Windows lower versions. Hmm, they've killed it? I've tried from my own DX9.0c link here http://www.blitzbasic.com/Community/posts.php?topic=103301 which now takes us to: https://www.microsoft.com/en-US/download/details.aspx?id=34429 This might pose issues to other people too. |
| ||
| Doesn't Hybrid even work in 32-bit mode? I am a little surprised (and at the same time disappointed). |
| ||
| Does it work with an hybrid executable ? Here is the water shader above compiled with hybrid : ocean_test.zip I guess it would be good for ploppy to know if it happens for everybody on windows 10 or if it is specific on your computer/installation. |
| ||
| Hi Windows 10 user - ocean exec runs fine with no errors. 819200 tris. |
| ||
| Problem with that, Ploppy. MonkeyX can't do 3D DirectX 11... |
| ||
| Yes, but DX11 is nothing to do with GL. |
| ||
| Yes Mark has always favoured the majority - which is OpenGL. But for a Windows system that is not ideal - certainly when dealing with a commercial project. So yes, MonkeyX can't do DirectX 11. Actually taking your word for this, but ok. So basically Guy Fawkes, I know this is frustrating, but no current language will ever please all of the people, all of the time...You must choose what works for you - and stick to it! ie Blitz and DirectX (through Hardwired). |
| ||
| That ocean thing up there wont run on my Windows 10 box (64bit), tried compatibility settings, the troubleshooter... Dont even get an error message, it just refuses to start. As far as I can see as well I have all the dx related dll's in System32 Dabz |
| ||
| Haven't tried the compiled version yet(have a bit of an issue with running exe's ;-) but will try to see. Odd thing is that MS doesn't allow for DX9 to install anymore on Win10. Update: can't run the executable also and no error whatsoever. Perhaps this is because MS after the last update, no longer allows lower DX versions to be installed as it considers their latest DX11.1 omnipotent? MS goes Viki: |
| ||
| I have an idea that just might work! If you can get Hardwired DLL to work with Monkey / Monkey 2, then we CAN compile an HTML5 version. :D |
| ||
| Hmmm.... Nice thinking. I have to say I don't know a lot about html5 but if monkey can make direct calls to dll functions for html5 then logically why not. But then, I guess this would only work on html pages that are viewed with windows as directx is exclusively windows of course. So, at the same time I have my doubts.. |
| ||
| Does anyone have any thoughts on how we might do this? Is there a LoadDLL or CallDLL function or w/e IN Monkey ? |
| ||
| if monkey can make direct calls to dll functions for html5 Can you show me an example of that please? |
| ||
| Of what? |
| ||
| How to load a DLL file in monkey. |
| ||
| Doesn't Monkey use OpenGL instead for platform compatibility? |
| ||
| It doesn't matter. If I can get Hardwired to work for Purebasic, then shouldn't the same be viable for Monkey? |
| ||
| I am guessing that html5 is version 5 of the html script language, used in web page creation. If therefore you are aiming to use hardwired on a webpage remember that all kinds of systems access a webpage, not just windows. It may be possible to access a dll directly using monkey this I do not know but this may depend on the target language you compile to. But even if it is possible to access a dll using html5 script the final page will only be exploitable using a direcx ready windows system. You are most likely in for some serious compatibility issues here my friend. Besides, to view a page that 'relied' on the hardwired dll as a dependancy would also require it to be downloaded first before your page would be visible to the end-user, similar to swf files and thier need for adobe flashplayer. As Rick was saying, it is more likely that Monkey uses OpenGL for compatibility purposes, all web-based systems use opengl, so it is easily adaptable for a webpage. Directx is however not adopted by all systems. Hardwired does not use opengl (although I have looked into it, this will not be for a while yet). |
| ||
| Ploppy, I don't know how you find the time to keep talking to yourself about the subject of hard wired only doing DirectX... GF obviously doesn't grasp the concept of what OpenGL is, what DirectX is, what Monkey creates, what HTML5 can do, and how the internal of browsers work in general... I suppose it gives you something to talk about in between doing work on your library :-) |
| ||
| Hey, only trying to help. In anycase, it keeps me busy when I'm unable to acess my pc as well.... ;-) |
| ||
| lol @ Brucey. And I can't understand why GF wants to keep jumping from one ship to another. Doesn't Blitz/Hardwired fulfill your needs GF? If you want more than Windows/DirectX then you're better off with another system. You really don't understand the work involved to add every feature under the sun - for ALL systems. By a lone (part time) coder like Ploppy. |
| ||
| I am getting closer and closer to getting the x64 version of the compiler up 'n running... In the past days, I have been working on the compatibility bewtween the compiler, the compiled programs and the debugger. I have now managed to update the debugger for the 32-bit version (now takes the 64-bit integers, the double floating point and unicode variables into account), and the debugger equally now works for the x64 version. A good step forward. As per before, the x64 version is still very limited to what you can program, but now at least you can debug it... Progress, of a kind... Download prerelease Please feel free to let me know about any unexpected weirdness... |
| ||
| Sounds pretty good, but still can't execute Hybrid.exe possible due to the fact that Win10 update V1 doesn't allow me to install DX9. See post #112. When trying to execute getting the popup:  - Does anybody else get the same on Win 10 Pro x64? |
| ||
| Hmmm. I think I may have to install win10 to test this out to be able to pinpoint much quicker, something I would rather avoid. So I'm gonna try to install it to a second ssd and make my pc multiboot, that way I can have both wins. I think I have to reprogram a little of the init code so it recognises if the resident system has dx9 or not; if it doesn't but it does have dx11 it will default to that instead. |
| ||
| Okay, I have had a little play with the code. No guaranties, but you may be able to enter the IDE with Win10 this new release, executing a program you'll have to test however. If you do not have dx9, it may carsh out, I'm working on the dx11 by default bit...please test.... |
| ||
| Rick, try this new update for you, I hope this works. I have altered the graphics initialisation routines to automatically default to the resident machine's installed dx version. No promises, but it should work; Hybrid should now default to directx9 only if it is installed, otherwize it will default to directx11 for all rendering. For future developement, I have also included defaulting to DirectX12 if directx11 is not present either - but no directx12 function have yet been implemented yet into hardwired and will not for a while yet, I'm just laying a few backbones so to speak. I have added a few commands to help programs detect the presence of a version of DirectX. Dx9Present() - Returns true if directx9 does exist on resident system, false if not Dx12Present() - Returns true if directx12 does exist on resident system, false if not. Again this routine is included and works fine, it is however not useful for the moment, and is just included for future developement and stuff... The function Dx11Present() already exists, of course, and has done for a while... |
| ||
| Thanks Ploppy. Unfortunately this wasn't successful. Don't know why for theoretically it should, right? Tried executing files individually: Ran ide.exe > Resulting popup: "Blitz Basic i: blitzpath environment variable not found!" Ran blitzcc.exe > Resulting popup: "blitzcc.exe has stopped working A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available." Ran blitzcc_x64.exe > Resulting popup: "blitzcc_x64.exe - System Error: The program can't start because d3dx11_43.dll is missing from your computer. Try reinstalling the program to fix this problem." The installed DX version according to DXDiag.exe: 11.1 My girlfriend's laptop however has DX12 installed, so probably it's a limitation on my systems GPU(GeForce 8400M GS). I found a solution for reinstalling DX9: 1. I followed this link to download the DirectX End-User Runtimes(June 2010): https://www.microsoft.com/en-us/download/confirmation.aspx?id=8109 2. Created a System Restort point. 3. Unzipped in a temp folder. 4. Executed DXSETUP.exe 5. Ran Hybrid.exe > Resulting popup: "Blitz Basic blitzpath environment variable not found!" Funny thing is, I can now compile/run hb code and still have the choice between DX9 & DX11 and actually see a difference, so my guess is that Hybrid.exe still relies on DX9 to be pressent somehow, somewhere even if not used and only DX11 is installed? This is not desirable if you ask me, for MS made it pretty hard to install DX9 and I suspect that at some point will completely pull the plug. Also in future if Hybrid users wish to use only DX11 or DX12 then they would still need to install DX9, which perhaps doesn't make a whole lot of sense to them. This might be worth investigating before moving on, for it's the base to build upon. BTW: 32bit all works fine. For 64bit I haven't been able to compile yet, but as you said it's in progress. |
| ||
| Hello Rick, I have just finished installing Win10 onto my system, I am planning to make my pc multi-boot since I just bought myself a bigger SSD than the one I already have. For the moment, I am having a little difficulty in getting both windows working on the same pc. Although I have two different partitions, only one seems to boot for the moment. Somthing to do with the ms bootloader boll*cks without a doubt. I am going to have to dig a bit but I will find out how to do it, for I have read it is possible to do so. I have just got myself a 240GB ssd, and have split it into two equal partitions - one for Win8.1 (the factory installed os), and the other for Win10. But it's not easy getting this set-up working, so I'll have to battle a while. But in any case, that's another story. Anyway, once I got win10 installed (which is presently the only OS that works on my pc), the first thing I tried was to see if Hybrid works or not. I tested it with a few samples, and all works fine, in both DirectX9 and DirectX11 mode. I think I will have to look a little deeper into this to solve your compatibility problem. I'll get back to you on this one, but perhaps not in the next few days, as I have a lot of work (my actual job, not Hardwired) at the moment. But I will sort it out, or give it a damn good try ;-) |
| ||
| 2 words, Ploppy :: "VMWare Workstation" |
| ||
| Thanks GF, I'll check that out... |
| ||
| True VMWare(or the likes) is probably best way to test. I read something about dual boot not being supported by MS for Win10, but dunno if it's 100% true. I used VMWare a lot in the past, however now I don't like it much anymore, for even though it does the job very well, it has also become a real system hogger with services running when not even active. (really don't like that, too heavy on my system). I haven't tried any others yet, such as Virtualbox. Questions: 1. Did you install DX9 separately? 2. What is your current DX version according to DXdiag.exe(11.1,11.2 or 12.0)? 3. Did you install the november update of Win10 already (major update 1.0, comes with the auto updates)? |
| ||
| [Double Post] |
| ||
| No, I just updated my Win8.1 to Win10. Since directx9 is already part of the win8.1, I assume the Win10 install process just copied it over, unless it is part of the Win10 install package (for which I have doubts). In any case, I tested Hybrid right after installing Win10, no extra installation needed. |
| ||
| Hi Rick, this new update should possibly fix the no dx9 present problem.... |
| ||
| Hmm, that's interesting(puzzeling?). I upgraded from Win7 with all updates installed to Win10 and was working fine until the major Win10 update #1(or should we call it overhaul?). Didn't work anymore until I managed to install DX9. Can't really test on this system anymore as it now has DX9 installed. But it would be interesting to know if works on other Win10's update #1. - Anybody up for testing? |
| ||
| Ok, well taking above into account I just tried to run the new version just for seeing if still goes: First got the msg: "Blitz Basic blitzpath environment variable not found!" But when I ran 2nd time that was gone, so probably caused by Comodo/Avast trying to sandbox first. Then it didn't seem to be able to display the editor, but if I hovered the mouse over the icon in the taskbar and then maximised it..  It then showed fine full screen.  However I can't resize the editor to anything but full screen size. Perhaps the default editor window size is too high for my screen resolution(1280x800)? |
| ||
| Just to let you all know of a small personal achievement of which I am nonetheless proud. I have managed to install my factory default Win8.1 and Win10 on my pc with a multiboot loader, as often with windows installations this was not easy to accomplish. It has taken me a while to setup, but it's well worth it. This way, for future developement, I will be able to work on Dx12 and test if things work on Windows10. And now I have a 240GB SSD instead of my original 60GB one, I have more SSD for my applications. I have split the 240GB in two, one partition for Win8.1 and the other for Win10. Works like a charm. |
| ||
| @Rick Nasher: Check the ide.cfg file (think it's in \bin), as there may be some wacky x/y position in there. Just change to something sensible if so. |
| ||
| Good stuff Ploppy. Dunno if you were following the latest developments by Flanker on a UDP multiplayer library, but it's getting really nice. And if I'm correct that will allow you to kick out the obsolete DirectPlay code in Hybrid, which will lead to better future compatibility and easier multiplayer game creation. See the thread I started ages ago here from thread #44 and onwards for discussion, additions and tests. And also his worklog here. I think this combined with Hardwired/Hybrid would really allow for some great stuff to come. BlitzSupport you were right, the problem was in: win_rect 1472 124 2432 936 In the original Blitz3d cfg>prefs this line is: win_rect 0 0 640 480 This solved my issue as the other stuff won't fit my screen(1280x800 max). After this change, it retained my Windows settings when resizing automatically. |
| ||
| Hey Ploppy, how's it going. Any new developments or just taking a bit of well needed R&R? |
| ||
| Well, I'm still working on it (almost every day for a while each day). But for the moment, I have nothing to report. |
| ||
| Ah cool, just curious to see what your up to as most of your stuff has been pretty spectacular so far. Something else: Any idea if the original UDP routines in Blitz3D rely on DirectPlay or are they completely separate? If so Hybrid, contrary to Blitz3D won't ask for installing DirectPlay when installing under Win10, which is of course preferable. |
| ||
| I do not think the udp related functions are directly linked in any way to directplay, this is rather used by the other higher level net related functions (such as StartNetGame, see list in blitz3d manual). The udp functions use the winsock routines. |
| ||
| Cool. Then the standard Blitz UDP based library(no DLL's required) that Flanker is making for multiplayer gaming will be also very useable under Hybrid, so this means we can now already create a 3d multiplayer game that will be relatively easy to port to Hybrid x86/x64 with it's better capabilities and pretty much be guaranteed to run OK on newer versions of Windows to come. Actually with all the features of Hybrid(such as the GUI, PhysX etc), it probably would be easier to program it straight in Hybrid, but as you said be aware; subject to change/under heavy development, for now better to start a basic version in Blitz3D then when Hybrid's stabilized enough, port and extend to it? |
| ||
| Cool. Then the standard Blitz UDP based library(no DLL's required) that Flanker is making for multiplayer gaming will be also very useable under Hybrid, so this means we can now already create a 3d multiplayer game that will be relatively easy to port to Hybrid x86/x64 with it's better capabilities and pretty much be guaranteed to run OK on newer versions of Windows to come. Actually with all the features of Hybrid(such as the GUI, PhysX etc), it probably would be easier to program it straight in Hybrid, but as you said be aware; subject to change/under heavy development, for now better to start a basic version in Blitz3D then when Hybrid's stabilized enough, port and extend to it? "the standard Blitz UDP based library(no DLL's required) that Flanker, myself, & Guy Fawkes is making" |
| ||
| But this is the wrong thread for these kinda discussions(as it's kinda dedicated to HW/HB).. Lets go <here>. |
| ||
| Just wondering if there are any known issues with the latest release of Hybrid and Win x64 on Intel Integrated GFX drivers? |
| ||
| Oops, meant Windows 10 - 64bit version, using Intel graphics. |
| ||
| Any updates soon, @Ploppy? =) ~GF |
| ||
| I'll see what I can do for february. No promises, I have a lot of work on unfortunately so hardwired has had to be put to the side these past few weeks. |
| ||
| Ah still around.. GF must have been reading my mind. ;-) |
| ||
| I am still unfortunately going round in circles with the x64 version of Hybrid - it is taking me much more time than I would like. For the moment, I am encountering some stack related problems resulting in some very ugly mav's. So, I'm afraid I cannot yet announce the x64 version, but it is still in the works, and I will not give up on it. For the moment, I have decided to take a break from the x64 version, time to mull things over and perhaps later retry in a different way. So instead for the last week or so I have been working on a new sound module for Hybrid. Other changes have been made to the compatibility side of things, in theory compatibility should be improved for all machines from winxp to win10. Needs testing, of course..... |
| ||
| For christ sake. I'll add the damn compatibility for mp3s using the windows library myself. I will have my MP3s! :D I'm hoping you add support for MP4. That would be AWESOME! =D ~GF |
| ||
| If the license permits me to do so, I will - I have to keep it legally useable... |
| ||
| Shut up GF, you don't know what you're talking about, and show some respect. |
| ||
| Steve Elliot, do NOT tell me to shut up! ALLS you do is troll me and this ends HERE, jerk! I did NOTHING to you! LEAVE ME AND THIS THREAD ALONE! FOREVER! UNGRATEFUL T***! |
| ||
| T***! this kind of thing can't be allowed. |
| ||
| Then tell them to quit trolling me! I did NOTHING! |
| ||
| Personally, I don't wish to get involved. But I will say this, you both seem inseparable, as this bickering has been going on a long time between you two. Please both of you excuse my impertinence, don't take it the wrong way, but I can't help thinking of this image...  |
| ||
| Yes you did. That's rude, impatient and arrogant. Think before you speak. Guy Fawkes For christ sake. I'll add the damn compatibility for mp3s using the windows library myself. lol @ Ploppy. I just pull people up if they are acting as I just mentioned. Some never listen though. |
| ||
| GF is useful in this world, he will stimulate the creation of a new technology in the future : https://www.youtube.com/watch?v=dz4HEEiJuGo :D |
| ||
| @RemiD ..hahaha..this was hilarious..lol.. |
| ||
| We're gonna need more paper tickets! :D |
| ||
| Some 3d sound related commands have now been added to the Hybrid vocab.... |
| ||
| Some positional sound related commands have now also been added to the Hybrid vocab, I have also improved the 3d sound routines.... |
| ||
| I tested the 3D sound, i'm not sure it works as expected. I noticed two things : - first the 3D sound is updated only when the emitter entity is in view - secondly it doesn't seem to take into account the camera position/rotation, the sound is updated as if the listener is always at coordinates 0,0,0, and looking forward (Z+). BTW i'm glad to see you back on Hybrid, personally I don't wait much for the 64bits version, the 32 bits version would already be enough to replace Blitz3D if it is compatible on recent Windows version. I can only test on Windows 8.1 and Windows 7 at the moment, maybe i'll try to install Windows XP on my old laptop. |
| ||
| Thanks flanker, I will check that out... |
| ||
| I can test on Windows XP, Windows Vista, Windows 7, Windows 8.1, (when i have free time of course...) but please make it easy and quick to do the tests. (last time that i downloaded and taken a look, there were many codes, i was not sure what you wanted us to test...) For example organize your codes by date of creation/update and add a clear description of what it is. As you want. |
| ||
| Ok Flanker, I have worked on it, and yes I saw (heard) what you meant. Thanks for that. So I have looked at my routines and changed some things, it seems to be fine now... :) |
| ||
| Hey Ploppy, can you add a small update to allow for any font to be used to create 3D text models from font text? If not, that's ok. Thanks alot! ~GF |
| ||
| It seems better but still have issues when moving/rotating the camera, even going to a crash. For example this modified example from your UFO example : The camera freelook uses RotateEntity and this can make the program crash. Also, there are strange effects when moving the camera back and for forth (keyboard UP&DOWN) |
| ||
| Also, I just found a Hybrid Editor glitch. If there is already 2 tabs present in a line of code & you try to add 1 more tab & / or in any way alter it, it glitches up and types things in it shouldn't such as "If" becoming "Ifif", etc... ~GF |
| ||
| Also, when trying to turn left & right in blitz3d, I can turn left & right just fine, but the negative & positive axis' seemed to have switched at least on TurnEntity(). My left became right, and my right became left. Moving forward and backward with MoveEntity() however, seems to be fine. ~GF |
| ||
| Also, you should try this demo I made because for some reason, the graphics glitch the crap out on the entire computer. You'll have like 1 second if you're lucky, to hit escape without having to restart the whole PC. So I suggest you be careful after you compile this & heed my warning. You'll need user32.decls in your userlibs folder & you'll need to compile this as a .hb file in the latest hybrid, 32-bit, "Debug Mode". Simply uncomment "UseDirectX11" & watch the glitchy fireworks begin! I would REALLY love to know what's causing this and how to fix it. Here goes: GraphicsTest.bb: I will post User32.decls in a separate post. Thanks again, @Ploppy! :) ~GF |
| ||
| user32.decls: ~GF |
| ||
| I have run your code examples (with the last version of Hybrid) on 2 different computers with Windows 7 and the renders seem weird in some demos (compared to the renders of the same code examples i have done some months ago) and some demos are abnormally slow and some even freeze... Also i was not able to use the last version of Hardwired with Blitz3d 1.108, some functions were apparently missing in the decls/dll... Good luck anyway, |
| ||
| Thanks for all the input from everybody - I'm looking into all of it. Some may take some time to sort out, but I will let you know when I solve something. I will however say this - I am doing what I can to stay completly faithful to the Blitz3d command set, the Hardwired version should give the same results as B3D and should retain the exact same syntax. However, GuyFawkes I see in your code that you are using a userlib to access the windows api. This is all well and good, but by using these api routines you cannot expect to have the same results as with b3d. The internal construction of Hardwired is different, structures are arranged differently or extended and labels are not necessarily the same, and using functions such as FindWindow will return in different results. This is obviously because of the use of the new directx versions. I will let you know when I dissect your code a bit more. |
| ||
| @Ploppy>>Just to be clear : i have run your "testx.bb" codes not the ones of GF. |
| ||
| @Gf -> IDE bug fixed (or at least I think so ;D ).... |
| ||
| YAY! Thanks @Ploppy! =D |
| ||
| @Ploppy>>a suggestion for your code examples (for hardwired and hybrid) : use the resolution of the desktop or a common resolution (640*480, 800*600) in windowed mode rather than the best resolution of the graphics card in fullscreen mode, because sometimes a screen can not display the best resolution of the graphics card and it shuts down... And i have no idea how to reset it without rebooting the computer (which is very annoying) |
| ||
| I completely agree, it is better that way. I have already made this adjustment to some of the samples, but didn't do it to them all. I think I will though....just in case... :) |
| ||
| Ploppy. Did you get a chance to check out the above code I sent you? That is whack the way the screen is behaving. ~GF |
| ||
| I am already working on it GF. Recoding and optimising. Getting much better results, but not ready yet.... will let you know when poss.... :) |
| ||
| Thanks alot, Ploppy!! :) I appreciate the continued updates! :) ~GF |
| ||
 Just a screenshot for the moment, as the program is still in a gutted state before i sew it back together. In any case, this is just to demonstrate I am making some good progress with the default shaders in both dx9 and dx11. Lighting is about 80% done now, looking much better than before, fps have also been improved. Please note also that the dot3 texture blend has now been implemented (bump mapping). Later.. |
| ||
| That's EPIC, Ploppy! :) Did you ever figure out what was causing that god-awful glitch in my demo to the point of me having to power button & reset my entire computer? Thanks, Ploppy! ~GF |
| ||
| Hi GF, not entirely - in some ways yes because it has helped me pinpoint certain things that were not working as intended; which has in turn led me to other improvements and additions to my code, such as a major overhaul to my texture and image management system and a partial rewrite of my default shaders (taking into account an improved vertex structure incorporating blend weights (for mesh skinning purposes) and tangent/binormal information used for bumpmapping. I have also added the SaveBuffer function so one can save textures/images. Some image commands are now available in my new not yet released build too. Some of this is thanks to your test program, GF. In any case, it doesn't crash for me. When I can get it all back together and it all seems stable, I will release another update :) |
| ||
| Ah, no problem, Ploppy! =) You're constantly doing stuff for us! I'm just glad I could return the favor! =) When you get it figured out, please do let me know why it was doing that in the 1st place. I'd REALLY love to know! ~GF |
| ||
| ice-cool! |
| ||
| Hi Ploppy! =) Any luck? ~GF |
| ||
| Actually yes, with respect to quite a few aspects of my project. I have made a few major changes to hardwired and some new additions since my last release. At the moment, I am re-working the skinning routines. I had a go at this about two years ago and didn't quite get it working - quite frustrating for me as skinned meshes are of course a standard part of any modern 3d engine. I have now stopped relying on the d3dx animation controller and the d3dx skin container. Now skinning and animations are handled by my own code. D3DX routines are part of the directx package but do not reside in the directx dll's, they reside in their own dll's. All d3dx routines (written by the directx team) are 'helper functions', and are there to facilitate directx programming but are optional. This is why they are not included in the main directx dll; another one of the reasons is to save memory keeping the d3dx function separate. 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. For bone control I have created a system of being able to freely and easily control each bone, and linking them in when needed to the animation controller. The bone heirarchy system then calcautes the needed updated matrices and passes them on to the vertex shader. I'm not quite there yet, but I'm on the way to finishing this part. I'm quite confident about getting this done now. I have recently also been re-working shadows. A while ago, I tried this out on hardwired. Although being partially successful, it wasn't great. I used a well documented old method of using a elongated copy of entities involved with shadowing and projecting them onto a stencil, and then rendering the the scene using the rendered stencil to mask in the shadows. This method, although usable, is very reliant on the cpu and so slow's down resources. The new method I am now using is much more shader reliant and does not use copies of meshes but rather pre-renders the z-buffer info of the scene onto a pre-defined texture, using the each light as a camera. These rendered textures (the number of textures are dependant on the number of lights in the scene of course) are then used by the shaders are used to provide instant info for shadowing techniques. This is a modern method of shadowning, and much much faster than the older method. There is of course a greater amount of memory used by texture consumption, but I have devised a way of being able to configure the texture size for shadow projections, with texture size directly affecting shadow quality naturally. My shadow routines are almost complete - 95% is done on the c++ coding side, but I'm now tring to perfect the shader calcuations. Probably the biggest change I have recently made to hardwired is the decision to completely remove any fixed function pipline usage. I had before included this usage into hardwired - the ffp was even the default render for hardwired. I have however removed it because I found it unecessary in the end; it was complicating and slowing down my code, and at the end of the day there is nothing the shaders cannot perform in its place. Shaders are even much more powerful and flexible. So now everything flows through my own default shaders, so far it's going very well I am happy to say. Consequently the "UseHWShaders" command has now been removed, as shaders will now always be used - either the defuault hardwired shaders or the user-defined shaders. I have also recently discoved that the D3DX dll's have even been depreciated by Microsoft and no longer supported. Although these libraries are still valid, they are no longer for example issued by default in windows. This is why for those using hardwired, you have to redownload directx from the net in order to make it work. The d3dx routines are part of the directx package, but not in the windows factory release. Hardwired uses the D3DX side of directx for certain things, not many things but some. This includes matrix and geometrical math functions, and loading of x meshes. In any case I will be working on replacing these functions with my own versions of them, in order to render hardwired even more compatible with modern systems and eliminate any dependancy of the d3dx api. I may well coincidentally be able to release a new version within the coming week, I hope so. It seems definately faster, smoother, and I have made improvements on the lighting techniques too. The shaders are getting rather big now in code size!! I have also begun work on deferred lighting, not ready to release anything in the close future on that side. So as you can see, I'm working on quite a few things at the same time. It may seem like a messy way of programming but for me is sometimes essential, as one thing can lead to another and I may sometimes have to modify one module to make room for a modification to another. A real jigsaw but I guess I'm having fun with it on some masochistic level. Anyway, I'll let you know when I can. ;) |
| ||
| That's AWESOME, Ploppy! Yea! PLEASE DO keep me posted! I can't WAIT to test the new release! I HOPE it's out within a week! Keep up the GREAT work, Ploppy! ~GF |
| ||
| Will Hardwired be able to use SDK such as steam/steamvr, oculus rift sdk, etc ? |
| ||
| If it can correctly read a DLL, then yes. :) ~GF |
| ||
| Hello there, it has been a long while since I've been on this Blitz forum. I assume that "HW Blitz3d Help files" are to update the ordinary Blitz [ v1.108] and "HW BlitzPlus Help files" are to update the ordinary BlitzPlus. Is that correct?  |
| ||
| Hey! First, you're doing some AMAZING work here. I've always loved Blitz3D as a language, and its lack of support made me sad. I had some requests for things I've wished I had in Blitz3D over the years. I don't know if they're even possible or feasible to implement, but I'll throw them out there in case you're interested, along with some examples of why they might be useful: 1. Store label pointers to and recall label pointers from type fields. When I have a lot of different objects that behave differently it slows things down a little to have that massive Select statement. It would be much faster if instead I could just goto a pointer to an object's AI programming, without needing any if or select statements. 2. Store type pointers in multidimensional arrays. Sometimes I need a multidimensional web of type objects. An example of this is for a scrolling map, where a web of interlinked types can make for very fast scrolling without any if statements, just direct pointers to what is needed. However, the problem with this approach is that I can't put in a specific coordinate if I want to jump to a specific spot in the web, like I could do using an array. Instead I would have to have it step over one link at a time until it's reached the desired coordinates. Thanks for the consideration, and keep up the great work! |
| ||
| Hi Ploppy! =) Just making sure this thread doesn't die! =) Any updates on that nasty glitch I found? Thanks again, Ploppy! =) ~GF |
| ||
| Ploppy, I have a feature request. I am willing to pay for if needed. jlfrazier77 @icloud.com |
| ||
| Any Hardwired Updates lately, Ploppy? =) ~GF |
| ||
| I like how this project prioritizes things such as shaders over making it actually able to compile programs. |
| ||
| Is that a smart ass comment or a compliment? o.o; ~GF |
| ||
| Its just a fact. I'm confused on what his priority for this project is if him/her is focusing on functions irrelevant to making any B3D program compilable. I can't even compile anything cuz he/she removed half of the default functions. I'm guessing he wants to re-add them in some optimized form but I go here to find 14 threads of adding shaders and other elements even though the software is unstable as shit. |
| ||
| Ok. So you're complaining. Goodbye. I'm not talking to you again. You will NOT sap MY energy. ~GF |
| ||
| So I'm not allowed to criticize this project and should be blindly shouting "OMG BLITZ3D ON DIRECTX9!!111!11!!"? Ok then. |
| ||
| Chopped Minority has a valid point. The priority of the main release version of a project like this should be stability, with additional experimental versions to showcase and test the new and less stable stuff. You can't get anything done with a product when using it feels like juggling live hand grenades. I'd love to port a project I'm working on (based on this code: http://www.blitzbasic.com/codearcs/codearcs.php?code=1137 ) to Hybrid, but currently Hybrid is a crash fest. Also, I think it's time for a new thread as this one's currently over 200 posts long. |
| ||
| I agree. This is one of the reasons I stopped hoping and moved on to other things. Don't get me wrong all these are great but if you can't compile a simple shader in the b3d userlib part, unexpected crashes and most commands are not available then what do you do? Main thing I was talking about getting this opensource so that Ploppy can get some help in case there are other knowledgeable guys who are willing to jump in. Every bit of help either big or small counts. that's what opensource is all about. If he likes to be in charge with the outcome, he still can by rejecting or accepting commits, that's how git/github works. At least with the bug fixing, it will be out of the question since this is mandatory for a stable project. |
| ||
 |
| ||
| @RifRaf ~ You know if you cannot accept the fact that not everyone is politically correct 100% of the time, kindly fuck off to the other subforums. @Zethrax, RustkyKristi ~ Pretty much this. |
| ||
| |
| ||
| I have to agree with Chopped Minority and RustyKristi. One man efforts like this rarely complete whether you are a hater or lover. Whatever is produced is pointless if it is unstable. I hope for the best, but I'll not be using it for now. Jim |
| ||
| I do not recall Ploppy promising any specific deadlines to complete in any specific order. I also do not see where he has asked for any donations. So whether you use it or not is not an issue. He is working on something he is passionate about in his own time, and has been kind enough to share with the community along the way. RustyKristi wrote: Main thing I was talking about getting this opensource so that Ploppy can get some help in case there are other knowledgeable guys who are willing to jump in. Every bit of help either big or small counts. that's what opensource is all about. If he likes to be in charge with the outcome, he still can by rejecting or accepting commits, that's how git/github works. At least with the bug fixing, it will be out of the question since this is mandatory for a stable project. No, just no. It's not mandatory for someone to give you or anyone else their hard work to complete a project. I would not expect it to be stable until complete and that's something Ploppy has always been clear on. Saying he was not sure how far it would go, or how long it would take. Whatever your expectations are they did not come from the author. ChoppedMonkey wrote. You know if you cannot accept the fact that not everyone is politically correct 100% of the time, kindly fuck off to the other subforums. If you are impatient, and not willing to watch his project move at its own pace then I think you may better serve yourself by not visiting this area of the forum. As for me, I am very capable of observing and appreciating the mans efforts. If you want to prevent a ban from the forum entirely you may think of more tactful ways to express yourself. |
| ||
| If you want to prevent a ban from the forum entirely you may think of more tactful ways to express yourself. Yeah because posting a "Haters gonna hate" meme is to tactful. I'm just saying it would make more sense for him to prioritize stability before working on new additions to the engine. While a lot of the stuff being added is needed for B3D to gain any form of modernization, it can be pointless in the grand scheme of things should the engine not even work. Any programmer can tell you doing this kind of stuff is troubling for a project as big as this. A lot of the work that was done so far is impressive, better then anything I could ever write. What worries me is how any of this will actually work later down in the project's future, cause right now Ploppy's work can only be seen through pre-compiled demos. In the event though that I am further written off as a hater shouting nothing but nonsense, I'm going to hold off from making any further responses in this thread, unless Ploppy weighs in their own opinion on the matter. Best of luck on your work. |
| ||
| Chopped Minority, you're a jerk. LEAVE PLOPPY ALONE! He's made a GREAT sacrifice of his time away from his family to make this & was kind enough to share it with the rest of the community! I think what he's done is INCREDIBLE! I'd LOVE to see YOU try to do what he has accomplished! ~GF |
| ||
| No, just no. It's not mandatory for someone to give you or anyone else their hard work to complete a project. but this is what I wrote: At least with the bug fixing, it will be out of the question since this is mandatory for a stable project. I said it's mandatory to do bug fixes for a stable project, you have misquoted me here. Same sentiment with Chopped and Zethrax and as I have said I already moved on and not here to argue. I'm not forcing Ploppy to opensource his work I'm just merely stating my opinion. I for one greatly appreciate Ploppy's work but that does not mean we do not have the right to voice out our honest opinion without getting this "haters" comeback. Who said we are hating this project in the first place? We have anticipated on this since the early stages and those impressive worklogs. If any free game that was made with great love and effort can still allow honest or poor reviews, I don't see why it won't be the same here. This is an open forum if I'm not mistaken. If you expose your work to the public you must be prepared to be criticized good or bad. It's not all praises, like a true friend would say or do. Good Day guys. |
| ||
| Yeah this "Haters gonna hate" nonsense isn't helpful. No-one's hating. Everyone saying they think that the project needs better stability understands and appreciates that Ploppy is working on this as a hobby project and that how he approaches it is up to him. All any of us are doing is providing feedback on why we personally would have to think twice before starting a project using these tools. Just calm down. |
| ||
| @RustiKristi True but this isn't even a finished project or in beta. @the others.. I must agree with RifRaf and afaik Ploppy already stated before that this is sort of his baby and he doesn't care and owe anybody anything which is a perfectly valid choice. And he said he WILL release the source in case he won't be able to complete the project himself. But if feeling you're being done injustice, know better how to do this the right way and also feel brilliant enough, no start an opensource attempt yourself? Blitz3D code is opensource anyway. But if not capable to do that, how on earth would you've even be able to contribute to Ploppy's work? Sorry, but I don't see the point about all this but just b*tchin out of frustration of your lack of skill and not getting your way. If you can, then do us all a favour and go ahead and start building you own vsrsion. If can't then stop complaining about this. You're not helping anyone here, which is I think the main reason the whole forum exists(blitzers helping blitzers?), otherwise start a blog and start b*tchin and complaining about how evil the world has been treating you. ;-) Sorry in advance but if you guys are not very helpful or constructive in your whole criticism thing then this is just tread pollution, which doesn't serve any purpose but venting..(pushing air) Anyhow: live long and prosper. |
| ||
| Btw, if impatient you can always take Irrlicht for a spin, which is open source: http://www.blitzbasic.com/Community/posts.php?topic=101569# |
| ||
| if you guys are not very helpful or constructive in your whole criticism thing then this is just tread pollution, which doesn't serve any purpose but venting.. the suggestions were : I'm confused on what his priority for this project is if him/her is focusing on functions irrelevant to making any B3D program compilable. The priority of the main release version of a project like this should be stability, with additional experimental versions to showcase and test the new and less stable stuff. I have already posted about the same thing in the past and i agree... Why try to create many functionalities which are not essential and buggy instead of focusing on a few essential functionalities first (the goal at the beginning was only to have a directx 9 engine and still use the others Blitz3d functionalities). The critics are justified and reasonable imo. The people who always praise and never critic don't like reality... (being appreciative and being a fanatic are 2 different things...). But i agree that since it is not your project, and that you can't change it anyway, post your reasonable critics and then forget about it and go use another engine which has the necessary functionalities to make your tool/game. |
| ||
| @Ploppy>>A constructive suggestion : Try to separate each system (and have separate functions for each system) as much as you can. For example, a collision system/a physics system does not need to be part of the rendering engine. This way, if somebody does not like one system, or if a system is buggy, or if a system is not compatible with future os, the programmer can choose to use another external system. |
| ||
| Hi Ploppy, Recently I was trying to run Hybrid, and it won't start, I get this error ::  How do I fix " Compiler environment error - Unable to open runtime.dll? "  ========================================================================== While running Blitz3D [v1.108], & Hardwired code, I get an error running display_modes.bb, as follows " Too many parameters on dxUseDirectX11 False "  I'm running Windows 10, 64bit, on a tablet, Onda v919. |
| ||
| ..i dont want to hijack thread, but since it was mentioned here, i just wanna ask about this irrlicht wrapper. I clicked on link provided, but when i try to download, archive seems to be infected..does anyone have this irrlicht wrapper, clean ?? |
| ||
| Hey NaughtyAlien, I think I might have a copy of that lying in somewhere on my ext harddrive. I just checked the examples some time ago and did not get a chance to play around with it. I'll post the zip file when I get a chance. |
| ||
| Try this one, it's almost the same file size. http://www.mediafire.com/download/a8p7y9lz1pp94th/_bIrrlicht_Release_1.0.0.1.7z Scan results https://www.virustotal.com/en/file/824e7448eb541d229671c860fdc7927d31836c56db8b0feac4b051aa6457d2fd/analysis/1462857061/ |
| ||
| ..weird..every time i hit download button, page reload itself and new tab is some adverts..download never starts.. EDIT: It seems Opera messing with link..firefox download went smooth...thanks a lot.. |
| ||
| no problem, there was a slightly older version that I also got around 7mb but I thought that was from a different author. anyway cheers |
| ||
| @virtlands: [erased my nonsense comments] :-) Perhaps Ploppy is on a holiday with his fam or something. Or just very busy. |
| ||
| It is not the first time that we (Blitz3d users) see somebody announces that he is making a future proof, improved version of Blitz3d... So even if i am thanksful to Ploppy for what he is doing, forgive me if i am less enthusiastic than some of you... "hope for the best, prepare for the worst". |
| ||
| I just want to make a note, that in attempting to convert some B3D programs to "Hybrid", I encounter issues with the command: BufferDirty |
| ||
| I'm interested in using HW to update Tank Universal 1 from Blitz3d's native DX7 to DX9 minimum. Is HW suitable? What are the current issues? |
| ||
| If I wanted to use DX9 with a Blitz language I would try GMan's Bmx Irrlicht wrapper first. http://www.gprogs.com/ |
| ||
| munch I'll look into it but as TU1 is written in Blitz3d and my time is limited, I really want to do the minimum of code conversion. |
| ||
| MadJack I don't know status with NB, but i guess, that will be your best bet, language similarity wise, as well as API..Irrlicht mod is a nice option, but im afraid, language/engine API syntax wise, it will be full rewrite.. |
| ||
| na NB had an update recently which has fixed the remaining base issues for me. I was having probs with 3d sound but have integrated Fmod. So it's basically as functional as Blitz3d but much faster and DX9. Still lacks nicer built-in features such as shadows but does incorporate HLSL shaders. |
| ||
| @MadJack If you would like to stay with B3D, the irrlicht blitz3d port that I posted looks stable enough. I have not checked it thoroughly (just examples) but it looks good so far and is DX9, latest irrlicht 1.8 and with write your own shaders. I think you just need to purchase irrklang sound (DLL) license for commercial use. I wonder what happened to the author, he just left it there and never to be seen or contacted again. It's a shame and would be great if he put out the wrapper source. |
| ||
| @MadJack Dunno if aware of this already but the Irrlicht dll (from Aqualung) I've seen works OK under Blitz3d. |
| ||
| Yeah that's the same one Rick :-) |
| ||
| ..it seems to be for freebasic?? I cant see any BB file inside.. |
| ||
| Blitz3D works fine on win10(with an install of directplay). is there a worry of it not working on future versions? |
| ||
| hehe..that fear is present since w7 if i recall..but old bugger keep rolling :) |
| ||
| @Naughty Alien No 'bp' is BlitzPlus extension, but works just as well under Blitz3d. See Post#103 for a fps. @Ploppy BTW: How are you doing? All fine? Longtime no hear/no see.. |
| ||
| Just keeping this thread alive. =) ~GF |
| ||
| Yeah any news on this. I would love to hear of any advancements even if they are just small |
| ||
| I'd like to know as well! =) ~GF |
| ||
| *Bump* Keeping this thread alive! =) ~GF |
| ||
| Looks like Ploppy is working on some issues, or taking a well deserved break...Hopefully not a break-down though ;) |
| ||
| Keeping this up one more time in memory of Ploppy. :/ ~GF |
| ||
| Guys, I'm moving on to a different programmering applikation. Things are moving fast, and Blitz just aren’t able to keep up (for a long time now), I'm sorry to say. I LOVE Blitz and the raw text programming, and Ploppy gave me hope for a small miracle, but I must face that it has been (and will be I the future) overrun by the other much smarter and better, quicker and more up-to-date apps because the have a live team behind with constant updates, tutorials, forums. Best of luck to all og keep on programming :-) |
| ||
| You can still look for Blitzmax + openGL, bobysait will realease his Big-Bang engine soon (I hope !). There is a thread in the showcase section. |
| ||
| Keeping fingers x-ed. |
| ||
| I'm sorry to see that there still are no activity on this thread :-( So how are you all doing? Are you still using Blitz3d/hardwired for your game or have you moved on to other platforms maybe? - just curious! |
| ||
| I'm sorry to see that there still are no activity on this thread :-( Unfortunately, Ploppy passed away. :-( http://www.blitzbasic.com/Community/posts.php?topic=106535 |
| ||
| Ohhh, so sad. RIP Ploppy! |
| ||
| With the source we could play around with it and hold it alive....maybe. |
| ||
| His widow Véronique Witt said she'd let her cousin look into it, but apparently he didn't know what to do with it either for we never heard anything about this anymore. Bad thing is that for anyone(if any) interested in picking it up where he left off, there's no other way to contact her but through Ploppy's old email address, which might not be valid or not even answered anymore. Also don't know if she would appreciate being contacted about this, possibly ripping open the wound again. In any case, let me share the email address of Richard & Vero: phoebe8@... (also updated in here: Condolence Register - R.I.P. Ploppy) |
| ||
| I miss this guy for his talent, inspiration, calmness and his sense of humour. He told me I was the only guy (or probably just the first to mention it) that Ploppy was a Black Adder character. There again I am a huge Black Adder fan, and others probably got the joke. RIP buddy, damn shame you didn't get to finish your work :/ |
| ||
I agree. He was one of those odd little turnips you don't get across every day.. BA: Good, well done and your name is ? P: Ploppy Sir. BA: Ploppy ? P: Yes Sir. BA: Ploppy the jailor ? P: That's right Sir. Ploppy son of Ploppy. BA: Ploppy, son of Ploppy the jailor ? M: Ah ach no Sir. I am the first Ploppy to rise to be jailor.My father, Daddy Ploppy was known as Ploppy the slopper. It was from him that I inherited my fascinating skin diseases. BA: Yes you are to be congratulated, my friend, we, we live in an age where illness and deformity are common place and yet Ploppy, you are without a doubt the most repulsive individual that I have ever met. I would shake your hand but I fear it would come off. Apparently he(the actor) died in 2013.. Ploppy, son of Ploppy actor dies aged 76 May both Ploppies rest in peace. |
| ||
| Raises a glass of Blackadder's Bowel Basher to both Ploppies. |
| ||
| The ideas and dreams of people cease to exist when they are dead. :( |
| ||
| RIP Ploppy. |
   |