Worklog for Ploppy
Blitz Hardwired
Return to Worklogs
| ||
| I have added some new functions to Hybid concerning the playback position in a sound channel... SoundLength#(sound%) - Returns the length, in seconds of a previously loaded sound ChannelSeek channel%,seconds# - Immediately sets the playback position in a previously created shound channel, given in seconds ChannelPos# (channel%) - Returns the current playback position of a sound channel, given in seconds        |
| ||
| Here a few more sound related commands, this time related to 3d sound... Load3dSound%(filename$$) - Loads a sound just like the LoadSound command and returns a channel handle CreateListener%(parent_entity%,rolloff_factor#,doppler_scale#,distance_scale#) - Creates a listener, generally linked to the rendered camera, see b3d manual for more details EmitSound%(sound%,entity%) - Link a sound to an entity for 3d spacial calulations A small test demo has been added to the hybrid/samples folder, the name 3d_sound_test.hb.... |
| ||
| I have now added some simple sound related commands to Hybrid, the following commands now work as in blitz3d... LoadSound% file$ - Loads a sound sample into memory from a file in it's entirety (ie not streamed). For the moment, only .wav files can be loaded, but I plan on increasing the number of different audio filetypes parsed. FreeSound sound - Does what it says... PlaySound% sound - Just like the b3d command, this will play a previously loaded sound and return a new channel handle ChannelPan channel%,pan# - Set the pan for a channel, values are from -1 (left) passing through 0 (center) to 1 (right) ChannelPitch channel%,pitch% - Set the playback frequency for a channel, values are in hertz ChannelVolume channel%,volume# - Set the volume for a channel, valid values range from 0 to 1, however you can set to above 1 for amplified volumes ChannelPlaying%(channel%) - Returns true if the channel given in the parameter is playing, otherwize false. PauseChannel channel% - Pauses a channel ResumeChannel channel% - Unpauses a channel StopChannel channel% - Stops playback for a channel LoopSound sound% - Sets a sound to playback subsequent channels in a loop SoundPitch sound%,pitch# - Sets a default playack rate for a sound, value is given is hertz SoundVolume sound%,volume# - Sets a default playback volume for a sound, valid values range from 0 to 1, however you can set to above 1 for amplified volumes SoundPan sample%,pan# -Sets a default playback pan value for a sound, valid settings range from -1 to 1... Please note that for the creation of Hybrid, it was not possible to compile in the same way as Blitz3d for the sound module. This is because of license restrictions. Blitz3d/+ used fmod, a professional sound api, and these routines were inserted into blitz; this was part of the license Blitz Research had bought from fmod and legal to do this way. However, for the open source release, it was not possible to issue this version of fmod without breaching the license conditions. So, although using fmod was still possible using the open source version of blitz, it was only legally possible by accessing an exterior fmod dll. This was ok, but did not correspond to my goal of creating an all in one sound module. Hybrid therefore does not use fmod, after a LOT of research and testing I have decided to opt for the SoLoud sound library, which is now part of Hybrid and a good substitute for fmod. SoLoud has a very flexible license that provides me with exactly what I need, and I will be building upon this base to add other sound commands. I also plan to reintegrate streaming commands, audio cd access,3d spatial sound, and microphone access. I wish to add .flac file compatibility, but I do not think there will be .mp3 compatibility (although I would like to), this is due to the .mp3 licence restrictions. |
| ||
| I have made a little modification to the CamToTexture commands. The revised syntax is the following CamToTexture(capture_device%,texture%,offset_x%=0,offset_y%=0) - This command will copy the pixel data from the internal buffer to a pre-created texture at coordinates (offset_x,offset_y). I recommend you only use this command after a new frame, if you copy a buffer unnessarily you will encounter a drop in frame rate. New Ftp Functions - Example found in the sample file ftp_access.hb ReadFTPFolder%(url$$,user_name$$,password$$,port%) - This will read a ftp folder and return a download handle. Reading will commence instantly, if of course the url, user name and passwords are valid. One the folder has been successfully read, a all ok state will be given to the download (see explaination in previous worklog), and DownloadDone will return true. FtpFileCount%(download_handle%) - Once a ftp folder has been read, you can retrieve the number of files/folders by using this command. FtpFileName$$(download_handle%,file_index%) - This function will return the file name of the entry given in the parameter file_index (ranges from 1 to the number of entries). FtpFileSize%%(download_handle%,file_index%) - Same as above, but will return file size. FtpFileAttribs%(download_handle%,file_index%) - This will return the file's attributes. The following attributes are possible.... 1 - Read only 2 - Hidden 4 - System file 16 - File is a directory 32 - Archived 64 - Device 128 - Normal 256 - Temporary 512 - Sparse file 1024 - Reparse point 2048 - Compressed 4096 - Offline 8192 - Not content indexed 16384 - Encrypted 32768 - Stream 65536 - Virtual 131072 - No scrub data More details about these flags can be found here FtpFileDate%(download_handle%,file_index%,date_type%) - This function will return the date of the file given in file_index. Three date types are available, and is given in the third parameter... 1=Get the file creation date - please note that on certain Ftp servers, this date type is not used. If this is the case, the date 1/1/1601 is returned for date/month/year. 2=Get the last access date 3=Get the last date the file was written/modified FtpFileMonth(download_handle%,file_index%,date_type%) - Returns the month of the file FtpFileYear(download_handle%,file_index%,date_type%) - Returns the year of the file FtpFileHour(download_handle%,file_index%,date_type%) - Returns the hour of the file FtpFileMinute(download_handle%,file_index%,date_type%) - Returns the minute of the file FtpFileSecond(download_handle%,file_index%,date_type%) - Returns the second of the file FtpFileMillisec(download_handle%,file_index%,date_type%) - Returns the millisecond count of the file FtpFileDay(download_handle%,file_index%,date_type%) - Represents the day of the week for the file. 0 represents sunday, 1 for monday and so forth until 7 for saturday. |
| ||
|
Thanks so much to Jari for your insight and code. I have now
integrated a modified version of escapi into hardwired and have linked
it (so far) to the hardwired textures system. I have yet to refine the
code, but the basics are there, so I'm releasing because I want to show
off. Anyway, a test sample can be found in capture.hb. Naturally, if
you do not have a webcam, there is not much point in downloading this
release ;-D New webcam functions CountCaptureDevices%() - Will return the number of capture device on the resident system CaptureName$(capture_device%) - Will return the name of the capture device given in the parameter. Capture devices range from 1 to the number of devices available, this number can be attained using the above command. StartCam(capture_device%,width%,height%) - Turns on a webcam ready for use and initialises an internal buffer that webcam data is copied to. The sampled webcam data will be scaled up or down to the buffer depending on the size given in the parameter. If you, for example choose a small resolution (50x50 for example) the pixel data saved to the buffer will be faster than writing to a larger resolution; but however the image detail of course will be blockier. StopCam(capture_device%) - Stops a capture device and frees up all memory used by it. CaptureCam(capture_device%) - This command tells the system to to update the internal buffer with the current webcam view. Hardwired(+escapi) will then begin updating. Once finished writing the new image the function below will indicate all done. CamDone%(capture_device%) - Returns true if the webcam update has been completed since the last capturecam commande, otherwize a 0 will be returned. CamToTexture(capture_device%,texture%) - This command will copy the pixel data from the internal buffer to a pre-created texture at coordinates (0,0). I recommend you only use this command after a new frame, if you copy a buffer unnessarily you will encounter a drop in frame rate. |
| ||
| I have since improved on the previous worklog... The syntax of the function Download has slightly changed, this is the new version... Download%(url$$,output_file$$="",flags%=0,temporary_file$$="") - The url parameter is the full http url address to be downloaded. - The output_file parameter defines the filename that the download will be automatically written to. - The flags parameter defines optional flags for this download. For the moment, the only flag available is the flag 1. If this flag is set, only the file size will be retrieved and downloading will then stop. - The temporary_file parameter defines the filename that the download will be automatically written to if you wish it to be written to a temporary file name during download time. Once the file has been completely downloaded the newly written file will be renamed to the output file name. If no temporary file name is supplied, the download will be written directly to the output file. Downloading to a file now works, an example can be found using the sample test1.hb. Please note that downloading to a file will automatically disable downloading to memory, freeing up the system and downloading to an output file on the fly. So, if you download to a file, you cannot use DownloadToBank (but you can of course load the file as usual from disk once completely downloaded). New function GetMyDocsFolder$$() - This function will return the path of the 'My Documents' folder on the resident system. |
| ||
|
Although Blitz3d has a way of connecting to the internet and accessing
the http protocol, it seems rather limited and unfriendly compared to
today's standards. As part of my ongoing task to bring new life to B3D,
I have created a new module that facilitates http downloading. This
module functions on a separate thread than the main program, so in this
way any downloading happens asyncronously and it does not hinder program
flow. This is a work in progress, so I still have commands/functions
to add but the basic stuff is ready. I plan adding uploading functions,
and ftp accees to this internet module. A small example of internet
access can be found in the sample test1.hb Below is a list of the functions presently available Download%(url$$,output_file$$="",flags%=0) - This will add a download to the download list. Parameters are as follows... - The url parameter is the full http url address to be downloaded. - The output_file parameter defines the filename that the download will be automatically written to. This is currently a work in progress and only downloading to memory is possible for the moment. - The flags parameter defines optional flags for this download. For the moment, the only flag available is the flag 1. If this flag is set, only the file size will be retrieved and downloading will then stop. The returned value of the download function is a unique handle for a successfully created download. SetProxy(default_proxy$$) - This will set the proxy address for all subsequent Download command calls by setting the parameter default_proxy. If a empty string is given, no proxy will be used - this is the default value for all downloads. SetPort(default_port_number%) - Sets the parameter default_port_number to the port for any subsequent Download command calls. The inital value for this parameter is 80, which is the standard comms port for http activity. CountDownloads%() - Returns the number of currently used downloads. DownloadUrl$$(download_handle%) - Returns the full url given in the Download command. ExtractHostName$$(url$$) - This function will split a valid url string and return the domain name only. ExtractPort$$(url$$) - This function will return a port number if one was supplied in the url address. ExtractUserName$$(url$$) - This function will return a user name if one was supplied in the url address. ExtractPassword$$(url$$) - This function will return a password if one was supplied in the url address. ExtractPath$$(url$$) - This function will return the path of the url used by the http domain that is called. DownloadState%(download_handle%) - The returns the current state of a download. Below is the current possible returned values and thier meaning... 1 - UNINITIATED; This value is given to freshly created download before the module begins to process it. If the download is part of several files being downloaded, it is most likely that the file is in a queue and has not yet been treated. 2 - INITIATED; The module has started to work on the download, and it tempting to connect to the internet 3 - OPEN_ERROR; The module failed to connect to the internet. Possible reasons for this could be a bad proxy name (or of course you forgot to plug your pc to your router, silly). 4 - CONNECTION_ERROR; The module failed to connect to the domain server. 5 - GET_REQUEST; The module succesfully connected to the domain server and is now making the request for the given file. 6 - GET_REQUEST_ERROR; The domain refused the request, was a valid URL given? 7 - PARSE_GET_REQUEST; The internet module is inthe process of downloading the file. 8 - CLOSE_REQUEST; The download has been completed, the internet module is in the process of cleaning up. 9 - SUCCESS_ALL_DONE; The download is now complete and all cleanup has been done. The current state is now in 'sleep' mode. 10 - PAUSED; work in progress - not yet complete 11 - DELETE_OBJECT - This state is used by hardwired to signal to the internet module to delete this download, including the downloaded data. DownloadSize%%(download_handle%) - This function returns the size in bytes of a download. If you set the flag to 1 in the initial Download command, only this filesize will be downloaded. DownloadRead%%(download_handle%) - The function will return the current number of bytes already downloaded DownloadDone%(download_handle%) - This function is a shortcut function that returns 1 if the download has a SUCCESS_ALL_DONE state, otherwize it returns a 0. DownloadToBank%(download_handle%) - This function will create and return a bank with the downloaded data in it. FreeDownload(download_handle%) - Use this command to free a download. If a download is not free, any downloaded data will remain in memory. If, for example, you use the DownloadToBank command on the download, it is advisable you use the FreeDownload commmand after or else you will have two copies of the downloaded data in your system ram. This will not of course in any way harm the system, but is an unecessary waste of space. Please note that this internet module is only presently available in Hybrid and not the Hardwired userlib. * I have also made some corrections to the SetWindowDefaults command. It should now work as anticipated. |
| ||
|
Small update for hardwired, but it took a lot of coding. The terrain
routines are based on the the original b3d lod algorithms and now behave
identically to the B3D original, they are dynamic and can be configured
with the SetTerrainDetail command - see the original B3d manual for
details. Using this LOD algorithm (level of detail) a significant
increase in FPS can be achieved without losing out on much detail.
Example can be found in test8.hb... |
| ||
| Text commands now function as they should in directx 11 mode. In addition to this I have added several new text manipulaton functions. A simple demo of these functions can be found in the special_text_modes.hb sample... New functions... TextRotation(initial_rotation#, additive_rotation#) This will instruct hardwired to render all subsequent text commands with a rotation on the string being output. The parameter initial_rotation sets the rotation z-angle for the first character output. In addition, a value can be added to each following character by setting the additive_rotation parameter. The default values for TextRotation are 0,0 TextSpin(initial_spin#, additive_spin#) TextSpin works similarly to TextRotation, however textspin will only affect each letter individually, and the spin of a character will not affect the position of the following characters, unlike with a rotation. For example, using a rotation as well as a spin for the inverse value of the rotation will rotate the line, but keep the characters of that line at 0°; therefore upright. Many different effects can be realised with these two functions. The default values for TextSpin are 0,0. TextScale(initial_scalex#,initial_scaley#,additive_scalex#,additive_scaley#) This command will use the same principles as the two above commands. The first character of a text line will begin with the font being sized by a factor given in inital_scalex and initial_scaley. Setting these two values to 2 will double the size, 0.5 would of course halve the scale. The last two values additive_scalex# and additive_scaley# can be used to add a value to the the initial scale values for each subsequent character drawn. Set these to 0,0 for no change. The default values for TextScale are 1,1,0,0. TextHandle(offset_x#,offset_y#) This last command will indicate to hardwired where on each character should the 'handle' or 'pivot' be. Rotational functions can be affected by where exactly a handle is located and will rotate the rendered graphic around it. The default values for TextHandle is 0,0; which indicated the top left corner of each character. Setting the offset_x to 1 indicates the right hand side, and offset_y will indicate the bottom of the character when set to 1. A setting of 0.5,0.5 for example will point to the centre of the character for clean spins. Negative values and values greater than 1 are accepted, and will extend handle 'outside' of the character's boundaries if required. Play with this command a bit to get the idea, but used in conjuction with the above commands can provide many different effects. You will notice that in dx9 mode, text is much faster than in dx11. I have yet to optimize my code for dx11, but that'll happen. |
| ||
| A small update today. Two new commands have been added.... INCDIR dirname$ Incdir is similar to incbin, but it will include any and all files from the folder name given in the parameter. This command is not recursive, no subfolders will be added. RecallFileFromDir%(dir_name$,file$) Use this command to recall a file from an archived folder. The dir_name$ refers to the foldername given in the incdir command (not case-sensitive), the file$ is the name of the file that you wish to retrieve (must be part of this folder, of course, or this function will fail). This function, if successful, will return a bank just like for the incbin command. Multiple incdirs are of course permitted if you have more than one, each folder will be added to the internal archive list. The addition of these two commands will permit the user to include many files in one lump, all coded into the compiled executable file. Please compile the sample hlsl_demo3.hb to an exe for a quick demo. |
| ||
| More update info on the change since the last pre-release update..... Text handling has been greatly improved in hardwired. Instead of using the resident windows functions to draw text directly to the screen when needed, my routines now create an internal texture containing each character from a font, these characters for the moment are only from the ascii charset, other glyphs will follow. When rendering text, this internal texture is used on 2d sprites, which are in turn rendered using the directx sprite handler. Rendering text this way is much faster, and makes use of shaders - much in the same way as fastext does. Please see test2_test for a quick (and very boring) demo. The difference in speed is quite something. I have yet to activate all of the new text related functions, but you can use the following two text functions already. TextOutline(enable) - Sets to true or false; will set all following text commands to draw all text with an outline colour. Default is true. TextAlphas(alpha#,outline_alpha#) - You can now set a transparency value for rendered text, the first parameter will set the alpha value for the text and the second for the text outline. Values range from 0 to 1. Update from yesterday - the bank returned by RecallFile now returns a valid readable bank. I will detail more about what's new tomorrow - it's getting late here now... |
| ||
|
A new part of the shader engine 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_type%,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 type - indicates the type of shader to be precompiled. Valid parameters are... 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) 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. 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 its wonderful work and will not need to worry about redefining the constants. ValidateConstants(shader%) Use this command when all constant declarations have been made, this will validate the shader and make it operable. 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). 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.... |
| ||
|
I have decided to pause the developement of the 64-bit side of Hybrid
in order to create a gamepad module for hardwired. This uses XInput
(part of directx), which is used in the majority of modern games for
gamepad input. Although mainly used for connected xbox gamepads,
playstation pads are compatible also with an outside extension (for ps3
controller owners please see here for more details, this works on most games too; which is great for ps3 owners that don't have a specific pc/xbox controller). Here is a rundown of the new gamepad commands, please see gamepad.hb for example.... dxCountPads%() - Returns the number of gamepads currently connected to pc, maximum of 4 dxPadPower%(pad_id) - Will return the current power level of a gamepad, supply the pad number for parameter pad_id (from 1 min to 4 max) Values returned are: 0 = Battery empty 1 = Battery low 2 = Battery medium 3 = Battery full dxPadBattery%(pad_id) dxPadPower%(pad_id) - Will return the battery status of a gamepad, supply the pad number for parameter pad_id (from 1 min to 4 max) Values returned are: 0 = No pad connected 1 = Device is currently wired and not using battery 2 = Alkaline battery 3 = Nickel metal hydride battery 4 = Unknwon battery type dxPadVibrate(pad_id%,left#,right#) - Sets pad n°pad_id to vibrate, parameters left and right are from 0-1; 1 being full vibrate dxReadPad(pad_id%) - Use this command to tell hardwired to read the all current inputs from pad n°pad_id. This must be called before using any subsequent commands listed below... dxLStickX#(pad_id%) - Returns a float value from -1 to 1 relating to the left stick's x-position, -1 being far left and 1 being far right dxLStickY#(pad_id%) - Returns a float value from -1 to 1 relating to the left stick's y-position, -1 being lowest and 1 being uppermost dxRStickX#(pad_id%) - Returns a float value from -1 to 1 relating to the right stick's x-position, -1 being far left and 1 being far right dxRStickY#(pad_id%) - Returns a float value from -1 to 1 relating to the right stick's y-position, -1 being lowest and 1 being uppermost dxPadA%(pad_id%) - Returns 1 if the A button was pressed at the moment of the dxReadPad being called, 0 if not dxPadB%(pad_id%) - Returns 1 if the B button was pressed at the moment of the dxReadPad being called, 0 if not dxPadX%(pad_id%) - Returns 1 if the X button was pressed at the moment of the dxReadPad being called, 0 if not dxPadY%(pad_id%) - Returns 1 if the Y button was pressed at the moment of the dxReadPad being called, 0 if not dxPadLTrig#(pad_id%) - Returns a float from 0 to 1 of the current position of the left trigger of pad n°pad_id dxPadRTrig#(pad_id%) - Returns a float from 0 to 1 of the current position of the right trigger of pad n°pad_id dxPadLShoulder%(pad_id%) - Returns 1 if the left shoulder button was pressed at the moment of the dxReadPad being called, 0 if not dxPadRShoulder%(pad_id%) - Returns 1 if the right shoulder button was pressed at the moment of the dxReadPad being called, 0 if not dxPadLThumb%(pad_id%) - Returns 1 if the left thumb button was pressed at the moment of the dxReadPad being called, 0 if not dxPadRThumb%(pad_id%) - Returns 1 if the right thumb button was pressed at the moment of the dxReadPad being called, 0 if not dxPadDUp%(pad_id%) - Returns 1 if the D-pad's up button was pressed at the moment of the dxReadPad being called, 0 if not dxPadDLeft%(pad_id%) - Returns 1 if the D-pad's left button was pressed at the moment of the dxReadPad being called, 0 if not dxPadDRight%(pad_id%) - Returns 1 if the D-pad's right button was pressed at the moment of the dxReadPad being called, 0 if not dxPadDDown%(pad_id%) - Returns 1 if the D-pad's down button was pressed at the moment of the dxReadPad being called, 0 if not dxPadStart%(pad_id%) - Returns 1 if the start button was pressed at the moment of the dxReadPad being called, 0 if not dxPadBack%(pad_id%) - Returns 1 if the back button was pressed at the moment of the dxReadPad being called, 0 if not |
| ||
|
Okay, this is not guaranteed to work. This update concerns mainly the
first prototype of the 64-bit version of Hybrid. I have managed to
compile my source to 64-bit without errors, so in theory it should work.
However it is very possible that it will not work; I unfortunately
cannot test this out for my machine is a crusty old x86 model. My
compiler vs2013 can luckily compile x64 versions nonetheless. So I'm
giving it a go, but no promises. What I will need is a little feedback from anyone possessing a x64 machine to see if they get anywhere at all with this version. I recommend you start off easy, try running/compiling a completely empty project for example and see what happens. If you have success move on from there to a simple program such as Print "hi" Delay 1000 End Do what tests you can, but please let me know as you guys will be my eyes. If I encounter a lot of errors, I will not insist too much (but I will a little) on the x64 version as I am coding blindly here. In this case I will just wait until I have a x64 machine before continuing down this road. Many modifications have had to be made in order to achieve a x64 version. I have finally removed all traces of directx7, as this is incompatible with Win64. The same applies to the directplay routines. This means that, for the moment, all commands that still used dx7 and dplay will now not work as I have 'emptied' them. The syntax still works and the program will run, but the functions do nothing. The commands that are affected by this update are mainly the functions concerning 2d graphics. However, any program run in a 3d environment should work as normal (in 32-bit mode, 64-bit TBC). In some respects, this update is a step backward, as some commands do not work anymore - but this is also a step forward towards a 64-bit version. I feel that a 64-bit version of Hybrid will help bring it up to date with modern technology, so I'm doing what I can to make it so. In any case, I will re-program all removed commands so that they are compatible with non dx7. Please note that I have not released a 64-bit version of the hardwired.dll. I consider it pointless to do so as Blitz3d that would use hardwired as a userlib is by nature incompatible since B3D/B+ are 32-bit. Modifications have been made to the ide to incorporate 64-bit compilation. I have added a new icon to the toolbar, and new entries to the ide menu for executing or compiling and saving x64 versions. If you try compiling a 64-bit version on a 32-bit machine, this will not work as the compiler for the 64-bit code is itself presently 64-bit also. I may possibly be able to create the 64-bit compiler as 32-bit code - but I will see about that later if possible. In any case, to clearly separate 32 and 64-bit code I have kept the two architectures apart for the debug, runtime, linker and compiler code. Other things worth noting * Font handling has now been reworked in hardwired, and the current set font will be used for gui button creation (see gui_test.hb) * Requesters have now been added and work just like in b+ * The initial default window that appears when executing a Hybrid program is now a hardwired window. Before, it was created by the original B3D source, but since this contained some DX7 linked code I had to replace it. This window, as before with Hybrid will not show upon running and will only unhide itself if you output text or graphics to it or if an it enounters a mouse or keyboard command. * Joystick commands do not currently work, as I have removed them. These were part of the directinput routines and so incompatible with x64. * Same applies to the muliplayer commands. |
| ||
| The gui event commands have now been added, please see the B+ manual for details. Have updated gui_test.hb also... |
| ||
|
All the original menu commands have now been added to the GUI routines,
see improved gui_test.hb for an example, and of course the BlitzPlus manual for a more in-depth explaination of the following menu commands. dxWindowMenu%(window%) dxCreateMenu%(text$,menu_id%,parent_menu%,make_sub_menu=false%) dxSetMenuText(menu%,text$) dxCheckMenu(menu%) dxUncheckMenu(menu%) dxEnableMenu(menu%) dxDisableMenu(menu%) dxMenuChecked(menu%) dxMenuEnabled(menu%) dxMenuText$(menu%) Please note the following: * Although I have completed the menu creation/edition routines, for the moment I have not done the event detection routines. So for the moment, this is just for demostration puposes but menus do work nicely now. * I have added to the previous syntax of the CreateMenu command. There is a new parameter at the end of the syntax which is now the following... CreateMenu( text$,menu_id,parent,make_submenu=false ) I have added the make_submenu option to the syntax to give the user the option to create a sub-menu in Hybrid. This was to my knowledge not possible in B+ so you were restricted to just a one-level menu system. Now you can create sub-menus by supplying true as the submenu parameter and this will signal the CreateMenu routine that the menu item being created will have a submenu. The handle returned by CreateMenu can then in turn be used as a 'parent' for new items that appear in the submenu. See a working example in gui_test.hb. To keep in accordance with the B+ syntax, if you do not supply a make_submenu parameter the command will default it to false, and will perform the same actions as a classic B+ command. |
| ||
|
Hardwired is currently undergoing some serious changes as far as the
way it handles windows. I am still in the process of preparing
Hardwired/Hybrid for the 64-bit version, and for this I will need to get
rid of the old directx7 commands that still exist in the Hybrid code
for all 2d routines. This code I did not touch until now as these
commands are to all intents and purposes independant of the 3d side of
things. To help bring things in-line and to increase Hardwire's all-round versatility and power I am bringing in BlitzPlus's GUI command set. I have added almost the whole of the command set for the moment, but a good part of these commands are just 'duds', that is to say that I have set up the command syntax but for some the routine has not yet been written. Below is a list of the commands that have been (more or less) completed (demo in gui_test.hb). Naturally, in Hybrid all the commands below have the syntax without the preceeding 'dx'... dxCreateButton%(text$,x%,y%,width%,height%,group%,style%) - See B+ manual for more details dxCreateComboBox%(x%,y%,width%,height%,group%,style%) - See B+ manual for more details dxSetGadgetText(gad%,text$) - See B+ manual for more details dxShowGadget(gad%) - See B+ manual for more details dxHideGadget(gad%) - See B+ manual for more details dxEnableGadget(gad%) - See B+ manual for more details dxDisableGadget(gad%) - See B+ manual for more details dxActivateGadget(gad%) - See B+ manual for more details dxGadgetText$(gad%) - See B+ manual for more details dxGadgetX%(gad%) - See B+ manual for more details dxGadgetY%(gad%) - See B+ manual for more details dxGadgetWidth%(gad%) - See B+ manual for more details dxGadgetHeight%(gad%) - See B+ manual for more details dxGadgetGroup%(gad%) - See B+ manual for more details dxCreateLabel%(text$,x%,y%,width%,height%,group%,style%) - See B+ manual for more details dxCreateProgBar%(x%,y%,width%,height%,group%,style%) - See B+ manual for more details dxUpdateProgBar(prgbar%,progress#) - See B+ manual for more details dxCreateSlider%(x%,y%,width%,height%,group%,style%) - See B+ manual for more details dxCreateWindow%(text$,x%,y%,width%,height%,group%,style%) - See B+ manual for more details dxActiveWindow%() - See B+ manual for more details dxActivateWindow(window%) - See B+ manual for more details dxMinimizeWindow(window%) - See B+ manual for more details dxMaximizeWindow(window%) - See B+ manual for more details dxRestoreWindow(window%) - See B+ manual for more details dxWindowMinimized%(window%) - See B+ manual for more details dxWindowMaximized%(window%) - See B+ manual for more details The following is a list of commands I have added to the GUI command set that I feel make useful additions... dxFreeGadget(gad%) - Will as the name suggest delete a given gadget dxCountWindows() - Returns the number of open windows dxFirstWindow() - Returns the handle of the first window in internal window list or 0 if no windows currently open dxNextWindow%(CurrentWindow%) - Returns the handle of the next window in the internal window list from the window given in the CurrentWindow parameter dxHideWindow(window%) - Hide a window dxShowWindow(window%) - Show it dxWindowToFront(window%) - Self explanatory! dxWindowToBack(window%) - Also self explanatory! dxPositionWindow(window%,x%,y%) - Position a window at x,y screen coords dxMoveWindow(window%,x%,y%) - Move a window by x,y dxResizeWindow(window%,width%,height%) - Change a window's size dxWindowWidth%(window%) - Returns a window's width dxWindowHeight%(window%) - Returns a window's height dxWindowX%(window%) - Returns a window's x coordinate dxWindowY%(window%) - Returns a window's y coordinate dxWindowResized%(window%) - Returns true is window has been resized by the user since the window was opened or the last dxWindowResized command on the window specified dxWindowMoved%(window%) - Returns true is window has been moved by the user since the window was opened or the last WindowMoved command on the window specified dxCurrentWindow%() - Returns the handle of the last window opened or the window selected with the command dxSetWindow/dxUseWindow dxUsedWindow%() - EXACTLY the same as above, I decided to create two commands that do exactly the same thing for the sake of lazy programming. dxSetWindow%(window%) - Sets current window that all following commands will use dxUseWindow%(window%) - Same as above, just a different commande name - again for the sake of lazy programming because I like both names dxWindowTitle(win%,title$) - Change the title name of a window to title$ I know there is still a lot to complete in this GUI module but it should come relatively fast now. You cannot presently do much with its current state, but I wanted to share my progress to show how far it is coming together and that I'm not sleeping ;D |
| ||
|
Today accounces the arrival of a special kind of Hybrid command, a
linker directive. Linker directives are part of a Hybrid program but
are not part of the final compiled code; these are however direct
instrucions for the linker itself. The linker is the part of Hybrid (as with blitz3d/b+)
that creates the final executable file once the code has been compiled
by the compiler, it essentially brings together the main program code,
the startup routines, the runtime functions(including hardwired), the
icons, the shaders. There will be a small and limited number of linker directives, but the commands I will add to Hybrid to be used as linker directives will be aimed at enhancing the Hybrid experience and at the same time help to render the final product more versatile and professional looking than possible before. These commands will be completely optional, of course. I am releasing my first linker directive today, a simple but in my opinion a very useful one... ICONFILE file$ - (Please note this command is in uppercase, I did this intentionally to differentiate this command from classic style command - to show it is indeed a directive and is not a part of the final program. Please see iconfile.hb Have you ever wanted to change the icon of a .exe you compiled with b3d/b+ rather than use the default blitz icon? I know I have. You can of course use an icon editor to change the icon after compiling, but I feel it is much better to be able to configure the final exe icon automatically without having to re-edit the file afterwards. With this new command, changing the icon is now possible. To change the icon just supply the filename of a valid .ico file, the icon will be copied by the linker to the final compiled exe file. See iconfile.hb for an exciting example.... Please note: You can use ICONFILE as many times as you wish in your hb program, but ONLY THE LAST command in your program script will be taken into account as the new icon for your exe file. If an icon filename you supply is not found or is not a valid icon, the program will not compile and an error message will be given saying as much. This may seem like a small addition to some but I think it really adds to Hybrid's user-friendliness. Other directives are planned, INCBIN and INCDIR. Both commands will be used to be able to include files or entire directories into the final compiled exe by using an archiving method. Access to these 'archived files' by the program for loading textures/sound/meshes/anything will be done using new commands. |
| ||
|
Mipmappng now correctly works in dx9 mode (mipmaps were not updating
correctly before, now behave as expected - see test6.hb for example). More bug fixes made to 64bit int and doubles. Even more solid. GetVersion$()/dxGetVersion$() will now return a string variable containing version number in x.x.x.x format (Major version.minor version.build number.revision number). My compiler has been set up to automatically increase and update the build number every time I re-build. |
| ||
| Hybrid has now the help files included with it.... Some bug fixes for the new types included in Hybrid - some memory leak issues have equally been resolved. |
| ||
| A nice new splash screen appear upon loading Hybid now, gives it that more polished look. Find and replace have now also been fixed and behave as should. |
| ||
|
Today I have spent some time debugging the IDE for hybrid. Some known
problems have now been fixed. Pressing Return on the keyboard was
creating two new lines at a time, not the usual one line -> corrected
(@GF - sorry about taking so long ;D). Pasting from the clipboard also
gave unpredictable results, sometimes changing the colour and/or font
of the text -> also corrected. I have also now officially changed the icon for Hybrid. I have chosen the logo created by Derron a while ago - and once again many thanks go to Derron. I personally think it is the best of the bunch, so here it is. Thanks to all for contributing to the logo request in any case - great to have input like this.... |
| ||
|
Another new release today, I have been principally working on
converting many of the original blitz commands to use the new
filetypes... OpenFile - Now will accept a unicode filename, now you can create that chinese/russian filename you always wanted! As usual if you supply a normal string variable $ it will automatically be converted to unicode, so compatibility is ensured. ReadFile - Same applies WriteFile - Again, same thing FilePos - Now returns an 64-bit integer value SeekFile - Accepts an 64-bit int value for large files ReadDir - Takes a unicode string as parameter now NextFile - Returns a unicode string CurrentDir - Ditto ChangeDir - Takes a unicode string as parameter CreateDir - Takes a unicode string as parameter DeleteDir - Takes a unicode string as parameter FileType - Takes a unicode string as parameter FileSize - Takes a unicode string as parameter CopyFile - Takes unicode strings as parameters DeleteFile - Takes a unicode string as parameter ReadAvail - Returns a 64-bit integer The following commands/functions have now been added to incorporate file access using the new types ReadInt64%%(stream%) ReadFloat64##(stream%) WriteInt64(stream%,value%%) WriteFloat64(stream%,value##) ReadUniLine$$(stream%) ReadUniString$$(stream%) WriteUniLine(stream%,value$$) WriteUniString(stream%,value$$) Unicode string manipulation The following commands/functions have now been added to help manipulate unicode strings... UniString$$(string$$,repeat%) UniLeft$$(string$$,count%) UniRight$$(string$$,count%) UniReplace$$(string$$,from$$,to$$) UniInstr%(string$$,find$$,from%) UniMid$$(string$$,start%,count%) UniUpper$$(string$$) UniLower$$(string$$) UniTrim$$(string$$) UniLSet$$(string$$,size%) UniRSet$$(string$$,size%) UniChr$$(ascii%) UniLen%(string$$) UniCode%(string$$) - This is the unicode string equivalent of the asc command. I have not called it UniAsc for example, as I do not wish to confuse unicode with asc. These are two different character sets. These commands function the same way as for the string manip functions for ascii strings, but are for unicode strings. You can of course use Mid$ for example on a unicode string, but since mid$ works on ascii strings, the parameter will be converted to a string before performing the mdi$ function. Any non-ascii character held in the unicode string would be lost during conversion so a mid$ could possibly return unexpected (but non crashable) results. Hence, it is best to use the string functions for string manips and unicode functions for unicode strings. |
| ||
|
I have got to a stage in the recoding of the compiler code for Hybrid
that I can release a new version containing the base code for three new
default variable types. These are the 64-bit integer, the 64-bit float
and the unicode string types. These are represented by %%, ## and $$
respectively. Most of the code is now complete, although there are some holes I am still working on it is now stable enough to release. Some commands have now been updated to take these new types into account. I am working on updating others... Text, Print and Write now use the default unicode filetype as thier default parameter type. If of course you provide a normal string variable for the command, the variable will be automatically converted to unicode so compatibility in ensured. Please note that these commands currently use unicode types in 3d mode only (after a graphics3d command). In normal default 2d mode, or in the default window any unicode character that is out of range of the ascii limits will not be displayed. I have yet to re-code the source for the 2d text routines so they accept unicode text. Filesize, Fileseek and FilePos are now configured for 64-bit ints, and no longer 32-bit ints. This means that files above the 4gb limit can now be accessed. Again, you can use 32-bit ints as before if you so desire and it will work as before with no change. All classic Blitz maths commands (sin, cos, tan, exp, log, etc...) have now been updated to accept and return 64-bit floats by default, although normal floats are also accepted, again automatic conversion in assured. For the moment, there are only two ways of defining a unicode character; one is done by defining it the classic way as you would for a string - such as string$$="hello"; this is only valid for any ascii characters of course as you cannot type any non ascii characters into an ide. Any string defined using this method will be converted automatically from ascii to unicode. The second mathod is used prinicpally to assign any non ascii character using the new UniChr(code%) command. Please see unicode_test.hb for an example. For a complete list of all unicode characters, i recommend you check out this site. I will be shortly be working on command equivalents for ReadInt/WriteInt for the new types. |
| ||
|
This worklog update is mainly for demonstrative purposes. Please check
out test11.hb to see an example of my work in progress on my particle
emitter code. I am in the progress of putting together a very configurable particle emitter system. A good part of it have now been written, and the renderer seems stable now, so here is an example of what is to come. Since the emitter system is very configurable, you can understand it will be accompanied with several commands to be able to program an emitter the way you please. I will soon publish another worklog entry will full details on the commands and how to create your own emitters. Particles created by the emitters are rendered using instancers, meaning a very fast display rate. Please note, rendering sprites using the emitter system will produce bizarre results for the moment. It is totally usable but won't display correctly. This I will of course correct, I have to update my shaders and incorparate the 'billboarding' technique. Please note also that for the moment particle emitters are NOT linked with Physx. They are however already looking good, and with Physx once I have incorporated that also, will look even better! |
| ||
|
After a lot of playing around with Phyx, I have my first mesh and
terrain routines operable. They still need some tweaking here and there
but they work... Meshes can now be inserted into the physical world as static objects without losing any triangular detail. However for dynamic actors, the meshes will be converted into convex meshes containing a maximum of 256 points. This is still a lot of detail, as you will notice in the new test2_physx.hb. Terrains can also now be used as static actors in the phsical world, test2_physx.hb demonstrates this also.... Some new commands... dxCreateMaterial%(static_friction#,dynamic_friction#,bounce#)Create a material with static and dynamic friction indices and a bounce factor. The returned material object can be applied to actors with the dxStaticActor and dxDynamicActor commands dxFreeMaterial(material%) Frees up a material - This will not affect already created actors Updated commands dxStaticActor and dxDynamic actor now have a second parameter, which is the material to apply to it. If no material is supplied, a default material of 0.5, 0.5, 0.5 will be used for friction and bounce. Please note: no point in trying to apply a texture to the teapots in the new demo, as this mesh does not presently contain any texture mapping coords. If you wan't textures, try it out on a loaded/user created mesh for example... have fun... |
| ||
|
Dynamic actor spin direction and speed are now updated as well as
position, see updated demo - looks even better than yesterday... New commands/functions dxGetVelocityX#(entity%): Returns an actors x velocity dxGetVelocityY#(entity%): Returns an actors y velocity dxGetVelocityZ#(entity%): Returns an actors z velocity dxSetTorque(entity%,x#,y#,z#): Sets the spin for an actor in pitch, yaw and roll dxGetTorqueX#(entity%): Returns an actors current local spin speed/direction on the x axis dxGetTorqueY#(entity%): Returns an actors current local spin speed/direction on the y axis dxGetTorqueZ#(entity%): Returns an actors current local spin speed/direction on the z axis dxSetMass(entity%,mass#): Self explanatory dxGetMass#(entity%): Same applies - you get the idea... dxWake(entity%): If a dynamic actor doesn't move for a while, Physx will consider it dormant and will not check on it's activity in the future to improve calculation speed. An actor will only 'wake up' if it is woken either by an outside force (i.e. another actor hitting it) or by giving this command. dxSleep(entity%):Manual sleep command - will put an actor to sleep immediately regardless of current velocity/spin speed dxSleeping%(entity%):Returns true if currently sleeping |
| ||
|
Since yesterday, Physx functionalities have changed as promised.
dMakeActor has been removed and replaced by two different commands
dxStaticActor and dxDynamicActor(see below). I have now configured Phyx
to accept hardwired cube and sphere entities. Please note that
non-uniform scaled spheres will for the moment not be calculated
correctly by my routines. I will be tightening up and adding things as
time goes by. Demo test1_physx.hb has now been completely changed, much
more demonstrative... What's new: dxInitPhysx(): Will load Physx dll's into the host machine and initiate it. This HAS to be the first Physx related command in a hardwired program or else any other Physx related command will cause the program to crash. dxSetGravity no longer will initiate Physx and will only SetGravity and that's all. dxStaticActor(entity%): Will set an entity as a static entity in the Physx world, a static entity will be present in the Physx world but will not be moved by Phyx. A static actor is used mainly for obstacles/floors/walls - things that do not move and therefore do not need to be calculated. dxDynamicActor(entity%): Will give an entity a dynamic presence in the Physx world and update it's position/rotation as time goes on dxSetVelocity(entity%,x#,y#,z#): Will set the speed of a dynamic actor in the direction of x,y,z |
| ||
|
This is the first and the experimental integration of Physx into
hardwired. I will of course be adding a lot to it, refining it and the
few existing commands may well change. This update is mainly to show
that it works (if it doesn't please let me know). The physx version I have integrated into Hardwired is the latest version available v3.3.2. I have decided to adopt this one to take full advantage of its power. For the moment I am using the dll version, and not the static library, so it is essential that the following dll's are found in the blitz3d/bin folder or the folder of the compiled .exe file.... PhysX3_x86.dll PhysX3CharacterKinematic_x86.dll PhysX3Common_x86.dll PhysX3Cooking_x86.dll If these files are not supplied in one of these folders you will not be able to use the Physx side of Hardwired. However, as with all vlc functionality, you will still be able to use any other part of hardwired without problem. I have included these four dll's in the Hybrid\bin folder. I have also included a very very simple little demo just to show physx really is running. I hope it works, for it was a bit of a b*tch to set up and link to my code. But now I have successfully linked Physx to HW, building up a command list should follow much quicker. Great stuff, it will really add to hardwire's power. The demo can be found using Hybrid, under samples\test1_physx.hb. There are only a few commands available for the moment, so you can't do much... dxPhysxPresent%():Will return true if the above files have been found in one of the right folders, therefore informing the program it is ideed capable of using Physx dxSetGravity(x#,y#,z#):Set the gravity for the Physx world, to a strength in x,y and z direction. This command also currently initiates Physx, without this command at the beginning of any Physx related code (apart from dxPhysxPresent which is independant of Physx itself) the program will crash. I will change this. dxGetGravityX#():Returns the current gravity x value dxGetGravityY#():Returns the current gravity y value dxGetGravityZ#():Returns the current gravity z value dxMakeActor(entity%):This will set up any hardwired entity into the Physx world, meaning that it's position and rotation will be interactive with gravity settings of the physics world as well as with any other actors. For the moment, I have only configured Physx to record any entities as cubes. Polygons, spheres, etc will all become cubes in the Physx world for the moment. This will soon change, this is just my prototype code for testing... dxPhysicsAdvance(time_step#):Advance time in the physx world and update all actors' positions/rotations. Supply time factor to advance... I will repeat - These first commands are not necessarily the definitive versions, they are mainly there for demo purposes. In any case they should be stable. If not, like always be free to let me know |
| ||
|
I have been tightening up a lot of hardwire's code, and am beginning to
bring this back into the release bit by bit. Many bugs have been
eliminated along the way, and efficiency has been improved. More to
come.... |
| ||
|
After some negative feedback concerning my last release, I have
re-programmed certain aspects of Hybrid - here's hoping no more
surprise visits from Mr Blue Screen! |
| ||
|
This update concerns principally all 2d commands. When I began
integrating hardwired into the b3d source, I disabled all directx7 code
in order to facilitate the integration of hardwired. This included all
2d commands. These 2d commands has now been re-established and should work as before. All 2d commands will continue to use dx7, like before, as this should not conflict with the dx9/dx11 side for 3d. There is also a very nice little improvement (Hybrid only) I have made to the compiler. This concerns the default output window for an compiled exe. In B3D/BlitzPlus the default window is displayed immediately even if you do not want it. I do not much like this personally, perhaps for some this is fine but for me it seems a bit ugly for my requirements. So now I have programmed this window to ONLY come up if the bb code sends a graphical ouput instruction (print, line, etc.) or an input instuction. If none of these commands are used, the window will not appear. Examples EndThis silly piece of code will do nothing, where as in B+/B3D it would have bought up the output window and then closed it Print "hello" EndThis slightly less silly piece of code will bring up the default output window because an output command has been used on it. It will then of course close just as quick. Waitkey EndThis code will also bring up the default output window as an input commmand has been used on it. Graphics3d 800,600,32,2 Print "hello"This code will not bring up the default window because the Print command is called on the newly created Graphics3d window. |
| ||
|
Changes have been made to Hybrid's compiler code to improve stability.
Exe's can now be compiled without resulting in an MAV (always a good
thing!) More sample files have been converted to Hybrid also... |
| ||
|
New small update out, but vital it seems, to give the user the chance
to change the default colour used in the IDE. Colour requester found in
the edit menu of the IDE. Once chosen, all new windows will use this
colour. Saves to preferences when quitting out of IDE. Enjoy... |
| ||
|
Hybrid now has it's own personal IDE, and it's own filetype .hb, it
will still read .bb files of course but will save by default any file to
the .hb filetype, so as to differenciate between b3d files and hybrid
ones. Please report any bugs, as there will be plenty - I have restructured much and re-done the b3d compiler side of things. |
| ||
|
I have been spending the last week redesigning my texture/image
handling routines so that both the directx9 and directx11 modes are
easier to bring together by 'wrapping' certain dx commands. This means
for me a lot less headaches in the long run since I will be able to use
the same routines for both directx modes. The technical stuff aside, all this means that more parts of hardwired are now functionable than before in dx11 mode. Graphics can now be written to textures using the classic graphics commands (dxplot, dxline, dxoval, etc.). Texture buffers can now also equally be accessed with the usual functions (dxreadpixel, dxreadpixelfast, etc.). Text commands and backbuffer/frontbuffer access should not be too far away now for dx11, but not quite ready... I have also reprogrammed dxCreateTorus and dxCreateTeapot - these two commands no longer use the directx9 functions; this is because the two functions do not exist in directx11. So now these have been completely rewritten by myself, making them usable in both dx9 and dx11 modes. For example, the teapot mesh was essentially 'grabbed' from a original dx9 mesh created by microsoft's in-built function, saved as vertex/triangle data, compressed and incrusted into the hardwired dll. My routine uncompresses this data, and creates a mesh from it. So, now that compression is part of hardwired I have decided to create commands to make it available to any user that may find it useful. The compression/decompression algorithms are designed to work on banks, not files. Below is a list of the relative functions.... dxCompressedSize%(compressed_bank%) - This will return the compressed size of the given bank dxCompressBank%(uncompressed_bank%,compressed_bank%) - This function will compress the data in the bank given in the first parameter and save the result in the bank given in the second parameter. The destination bank MUST be created beforehand, and have at least the size give by dxCompressedSize in order to function correctly. Failure to do so will most likely result in a memory access violation. dxDecompressedSize%(compressed_bank%) - This function will return the decompressed size of the given parameter. Use this function to create the necessary bank for decompression. dxDecompressBank%(compressed_bank%,uncompressed_bank%) - Decompresses the compressed data held in bank1 into the previously created bank2. The size of the second bank is available using the dxDecompressedSize() function. Other improvements *Vertex colours are now rendered when the entity/surface fx flag 2 is used *My graphics routines (dxplot, dxoval, dxline, dxrect) have also been optimised on the dx9 side of things, results are faster than before. *Left and right shift key detection has now been fixed. *XP compatibility has also been improved. I have yet to test it out on an xp machine, but I am hoping for the best as always... |
| ||
| Ok, XP Users, this may work now. I haven't yet tested, but I think I have found out why it wasn't working before... |
| ||
|
I have added some more flags since my last update this morning and now I
have uploaded again. There are now four additional flags for
dxSaveMesh... 4 - Save textures This flag will signal dxSaveMesh to save all textures that the mesh and it's surfaces are linked to. The filename of a texture is defined by the texture name (changeable using the command dxNameTexture, dxTextureName retrieves current name for a texture. If the texture name is an invalid filename, the texture will be skipped. If the file already exists, the file will not be overwritten and the saving will be skipped also. Please note that if a texture is referenced by more than one surface, the texture in question will only be saved once. 8 - Overwrite texture With this flag set, textures will be overwritten if the files already exist, as opposed to the default "do not overwrite" 16 - Rename texture With this flag set textures will be saved in the same folder as the mesh to a newly designated filename beginning with "texture_" followed by a six figure number. For example, if the filename "texture_000001.*" does not exist, this will be used, if not however the number will be incremented by 1 until a unused filename is found. The extension of the file depends on the texture's flag settings. If the texture's flags indicates the texture has an alpha channel, the extension will be ".png" and the file format will be thusly in PNG file format. Otherwize the extension will be ".jpg" for a JPG format image. Please note that if the default filename supplied in the texture's name is a invalid filename, the rename texture flag will also save the texture with a newly formatted name. Any renamed texture will automatically have thier name changed within the texture object equally. 32 - Force PNG Setting this flag will force the dxSaveMesh command to save any renamed texture to a png format, regardless of the presence of an alpha channel within the texture image. Phew! I hope this all makes sense (and that it works ;D) |
| ||
|
For the past day I have been working on a command which is in my
opinion a great addition to hardwired - something that was missing from
b3d. The ability to save meshes to a file. Saving to a b3d file now works. Below the syntax.. dSaveMesh%(filename$,entity%,flags%) For the moment, only saving to the b3d file format will work. Be sure to include the ".b3d" file extension in the filename. Once I have included the ability to save to the 3ds format or x format, the format to save in will be dependant upon the file extension of the filename. This way I do not have to incorporate three different commands, all will be rolled into one. Please see dxsavemesh.bb for a simple example. The entity parameter refers to the mesh you wish to save - please note that ONLY meshes can be saved for the moment. I am also working on the bones part - so for the moment this info is not saved to file; but it's on its way.... The flags parameter gives options for saving to a b3d file, these options can be OR'ed... 1 - Do not save any normals information for the vertices contained within 2 - Do not save any colour information for the vertices contained within More options will follow... dxSaveMesh can be used as a function as much as a command, it will return 0 if the function fails for some reason (mesh is empty/invalid file name/entity not a mesh) and 1 if the function succeeds. |
| ||
| The following corrections have been made dxEntityX,Y and Z now return the correct value when dxreturning a local value dxEntityPitch,Yaw and Roll behave similarly now The following has been added to dxloadmesh... Automatic texture loading for b3d models - if the file contains texture information hardwired will now behave identically to b3d, loading automatically each texture. Automatic brush creation - if the file contains brush information (colours, shininess, texture assignment, etc.), hw will now create a brush for each brush entry and assign these brushes to surface that require them. |
| ||
|
Numerous corrections have been made in both hardwired and hybrid. Some
visible, some not. Improvements have also been made for machine
compatibility - this may work once more on windows xp.... No new commands just yet... |
| ||
|
I have decided to release Hybrid as part of Hardwired. So for every
new update, be it for Hardwired/Hybrid or both I will release the lot in
one easy to swallow losange. Hybrid can be found in the Hybrid folder of the Hardwired release zip archive. The hardwired dll can be found, as usual, in the root folder of the archive, I have not included it in Hybrid's userlibs folder. If you wish to copy it to the userlibs folder you can; it should be compatible. But there is not much point in doing so, for all the hw commands will be part of Hybrid's runtime library. If however you wish to use the issued hardwired test demos that are in the archive zip, you will need to use the userlib. The demos use the dx prefixed commands. The Hybrid version of the commands does not have this prefix. I have taken away the prefix to ensure compatibility with hardwired and to replace the original b3d commands. Please note that you cannot mix Hybrid and Hardwired code as these modules do not communicate between them. |
| ||
|
Hello, I have been adding a lot of previously Hardwired exclusive
commands/functions to Hybrid's vocabulary today. New version has been
uploaded for your enjoyment... Download Hybrid HARDWIRED COMMANDS/FUNCTIONS HARDWIRED PRESENTLY ADDED CreateTeapot AutoCameraAspect CameraFOV GetCameraFOV GetCameraAspect CreateTorus GetEntityFX EntityWireframe Pointframe EntityPointframe CreateText 3DFont UpdateSurfaceNormals WBuffer PixelShaderVersion VertexShaderVersion CreatePixelShader FreelShader CreateVertexShader EntityPixelShader EntityVertexShader GetLastShaderError CountEntities GetSurface FirstEntity NextEntity PreviousEntity GetVersion GetEntityAlpha FreeSurfaceAttribs SurfaceFx SurfaceBlend SurfaceAlpha SurfaceWireframe SurfacePointframe SurfacePixelShader SurfaceVertexShader SurfaceColor SurfaceTexture WritePixel TextureSave CopySurface CopyImage SetFilters RenderToTexture RenderToScreen ScaleSprite UseDirectX11 DirectX11Used BufferNoise BufferInvert GetSurfaceBoundingRadius TrisRendered MaxLights GetConstantTableSize ConstantCount%shader DeclareVertexShaderWorldConstant DeclareVertexShaderViewConstant DeclareVertexShaderProjConstant DeclareVertexShaderWorldViewProjConstant GetEntityType GetFPS FramesRendered HideWindow IsWindowMinimized $GetWinVersion SurfaceShininess CreateMaze FreeMaze ReadMaze SaveMesh LoadMeshXFromBank LoadTextureFromBank PeekMemInt PokeMemInt LoadAnimTextureFromBank LightCaster EntityCaster EnityShadowDetail EnityShadowColor EnityShadowIntensity EnableShadows EnityShadowCutoff SetVSync SetWindowDefaults WinClose ScreenWidth ScreenHeight WindowWidth WindowHeight WindowX WindowY WindowResized WindowMoved MeshSimplify VlcPresent FreeVid VidLoad VidDownload VidTrackCount VidTrackType VidWidth VidHeight VidDuration VidTexture GetVidTexture VidPlay VidPlaying VidStop VidPause VidGetPosition VidSetPosition VidMuted VidMute VidUnMute VidGetVolume VidSetVolume VidGetSubtitleCount VidGetAudioTrackCount VidGetAudioTrackDescription VidSetAudioTrack VidGetSubtitleDescription VidSetSubtitle RequestFile VidGetPlayRate VidSetPlayRate Dx11Present BeginScene EndScene RenderEntity RenderCls GetMaxFeatureLevel SoftwareEmulation NoSoftwareEmulation LoadAnimMesh Animate SetAnimTime AnimTime Animating CountBones BoneName BoneX BoneY BoneZ BonePitch BoneYaw BoneRoll MoveBone TurnBone GetBoneParent GetRootBone CountBoneChildren GetBoneChild CountBoneSiblings GetBoneSibling ScaleBone BoneScaleX BoneScaleY BoneScaleZ CountBoneInfluences GetBoneInfluenceVertex GetBoneInfluenceSurface GetBoneInfluenceWeight FindBone RenameBone CountVertexInfluences GetVertexInfluenceBone GetVertexInfluenceWeight SetBoneInfluenceWeight FreeBoneInfluence BoneParent FreeBone CountCaptureDevices CaptureName OpenCaptureDevice CaptureWidth CaptureHeight UpnpSearch UpnpSearchDone UpnpCount UpnpName SetAnimKey AddAnimSeq EntityHWShaders HWShaders SurfaceHWShaders EntityNegative EntityTextureBoundary CreateQuat FreeQuat QuatFromEntity QuatFromPYR QuatFromXYZW GetQuatX GetQuatY GetQuatZ GetQuatW GetQuatPitch GetQuatYaw GetQuatRoll QuatFromMatrix QuatInverse QuatNormalize QuatMultiply CreateMatrix FreeMatrix MatrixMultiply MatrixInverse HWWinStatus CreateInstancer FreeInstancer InstancerCountElements InstancerAddElements InstancerFreeElement InstancerHookEntity InstancerUnhookEntity InstancerPositionElement InstancerElementX InstancerElementY InstancerElementZ InstancerMoveElement InstancerRotateElement InstancerTurnElement InstancerElementPitch InstancerElementYaw InstancerElementRoll InstancerScaleElement InstancerElementScaleX InstancerElementScaleY InstancerElementScaleZ CreatePlane Write TouchscreenTouched TouchscreenXPos TouchscreenYPos TouchscreenWidth TouchscreenHeight TouchscreenTime GetBrushTexture TFormVector TFormNormal CreateDouble FreeDouble DoubleMultiply DoubleDivide DoubleAdd DoubleSubtract DoubleToFloat DoubleToInt DoubleFromString DoubleFromFloat DoubleFromInt DoubleCopy DoubleToString DoubleSqrt DoubleSin DoubleCos DoubleTan DoubleASin DoubleACos DoubleATan DoubleATan2 DoubleSinh DoubleCosh DoubleTanh DoubleAbs DoubleLog DoubleLog10 DoublePow DoubleExp DoubleCeiling DoubleFloor DoublePi DoubleToRadians DoubleToDegrees DoubleSign DoubleEqualLessThan DoubleLessThan DoubleEqualTo DoubleEqualBiggerThan DoubleBiggerThan DoubleMod MakeTrayMessage MakeTrayIcon HardwiredLicence AutoPadding AddShaderConstant CountShaderConstants GetShaderConstantClass GetShaderConstantType SetShaderConstantType GetShaderConstantFlags SetShaderConstantFlags SetIntShader SetBoolShader SetFloatShader SetShaderConstantEntity GetShaderConstantEntity SetMatrixShader%shader SetFloat2Shader%shader SetFloat3Shader%shader SetFloat4Shader%shader SetInt2Shader%shader SetInt3Shader%shader SetInt4Shader%shader InstancerElementActivate InstancerElementActivated FreeInstancerElement EntityGreyscale EntitySepia EntitySimpleBlur CreateEmitter EmitterAddStyle EmitterCountStyles EmitterSetStyleShare CreateBehaviour FreeBehaviour BehaviourSetBirthPosition BehaviourSetBirthRotation BehaviourSetBirthScale BehaviourSetBirthDelay BehaviourSetLifeSpan CopyInstancer CountCollisions CollisionEntity EntityCollided CollisionX CollisionY CollisionZ CollisionNX CollisionNY CollisionNZ CollisionSurface CollisionTriangle CollisionTime CaptureWorld |
| ||
|
Here is the first version of a directx9/11 version of blitz3d. It has
been written from a modified base coming from the blitz3d source code,
incorporating the hardwired library (my source). I have decided to call
it Hybrid for two reasons. First reason is I don't think I should give
it a blitz name, after all it is unofficial and not a BRL release.
Second reason, Hybrid sounds quite cool - it is after all a combination
of two beasts rolled into one. Download Hybrid Ok, every single b3d command still "exists" for the moment, however the orignal dx7 source code has been taken away. So, for some commands/functions they will do absolutely nothing. However, for the rest of these commands, they will use my hardwired source code, which is fully integrated into the b3d runtime code. I am in the process of linking each command name with the hardwired functions. So patience, but they should come quite quickly. Below is a quick list of which hardwired commands are at present active. Please note that all hardwired commands/functions that use the dx prefix in the userlib will not have this prefix in the compiler, effectively replacing all b3d commands. Userlibs still of course work, but may not be compatible with this hybrid version of b3d. This is because some userlibs use dx7 functions so will not recognise dx9 stuff. Funnily enough, the hardwired userlib should work fine with Hybrid (although I have not yet tested this), but why whould you?? COMMANDS/FUNCTIONS CURRENTLY HARDWIRED ACTIVATED CountGfxModes GfxModeWidth GfxModeHeigh GfxModeDepth CountGfxModes3D Graphics3D EndGraphics FrontBuffer BackBuffer Flip GraphicsWidth GraphicsHeight GraphicsDepth SetBuffer GraphicsBuffer LockBuffer UnlockBuffer ReadPixel WritePixel ReadPixelFast WritePixelFast Color GetColor ColorRed ColorGreen ColorBlue ClsColor SetFont Cls Plot Rect Oval Line Text CopyRect LoadFont FreeFont StringWidth StringHeight Write Input Locate ShowPointer HidePointer WBuffer Dither AntiAlias WireFrame AmbientLight ClearCollisions Collisions UpdateWorld RenderWorld ClearWorld TrisRendered CreateTexture LoadTexture LoadAnimTexture FreeTexture TextureBlend TextureCoords ScaleTexture RotateTexture PositionTexture TextureWidth TextureHeight TextureName SetCubeFace TextureBuffer ClearTextureFilters TextureFilter CreateBrush FreeBrush BrushColor BrushAlpha BrushShininess BrushTexture GetBrushTexture BrushBlend BrushFX LoadMesh LoadAnimMesh LoadAnimSeq CreateMesh CreateCube CreateSphere CreateCylinder CreateCone CopyMesh ScaleMesh RotateMesh PositionMesh FitMesh FlipMesh UpdateNormals MeshWidth MeshHeight MeshDepth MeshesIntersect CountSurfaces GetSurface CreateSurface GetSurfaceBrush GetEntityBrush ClearSurface PaintSurface AddVertex AddTriangle VertexCoords VertexNormal VertexColor VertexTexCoords CountVertices CountTriangles VertexX VertexY VertexZ VertexNX VertexNY VertexNZ VertexRed VertexGreen VertexBlue VertexAlpha VertexU VertexV VertexW TriangleVertex CreateCamera CameraZoom CameraRange CameraClsColor CameraClsMode CameraProjMode CameraViewport CameraFogColor CameraFogRange CameraFogMode CameraProject ProjectedX ProjectedY ProjectedZ EntityInView EntityPick LinePick CameraPick PickedX PickedY PickedZ PickedNX PickedNY PickedNZ PickedTime PickedEntity PickedSurface PickedTriangle CreateLight LightColor LightRange LightConeAngles CreatePivot CreateSprite RotateSprite ScaleSprite HandleSprite SpriteViewMode CreateTerrain LoadTerrain TerrainSize TerrainHeight ModifyTerrain CopyEntity EntityX EntityY EntityZ EntityPitch EntityYaw EntityRoll GetMatElement TFormPoint TFormVector TFormNormal TFormedX TFormedY TFormedZ VectorYaw VectorPitch DeltaPitch DeltaYaw EntityType EntityPickMode GetParent GetEntityType EntityRadius EntityBox EntityDistance EntityCollided CountCollisions CollisionX CollisionY CollisionZ CollisionNX CollisionNY CollisionNZ CollisionTime CollisionEntity CollisionSurface CollisionTriangle MoveEntity TurnEntity TranslateEntity PositionEntity ScaleEntity RotateEntity PointEntity AlignToVector SetAnimTime Animate SetAnimKey AddAnimSeq AnimTime Animating EntityParent CountChildren GetChild PaintEntity EntityColor EntityAlpha EntityShininess EntityTexture EntityBlend EntityFX EntityOrder HideEntity ShowEntity FreeEntity NameEntity EntityName EntityClass DebugSilent DebugLoud DebugHarsh DebugLoudAndHarsh KeyDown KeyHit WaitKey FlushKeys MouseDown MouseHit GetMouse WaitMouse MouseWait MouseX MouseY MouseZ MouseXSpeed MouseYSpeed MouseZSpeed FlushMouse MoveMouse You will notice that the hardwired debug functions have been added. I just put these in to prove that I really have recoded b3d. As time goes by of course, I will be adding the whole of the hardwired command list, and all will become very clear that it is indeed a dx9/11 version. Please note the zip file does not contain the b3d help files. Please note also that for any sound oriented commands the fmod.dll file (found in the bin folder) will need to reside in the same folder as a compiled exe file. This is because blitz's system uses the library fmod for sound oriented functions. The original b3d's source intgrated fmod into all compiled exe's. However, this version of fmod (a static library and not a dynamic library) has not been issued with the released blitz3d source. I think this is probably because of a license restriction, at a guess. In any case, I will be looking into this - I will find a way around this in time. Not likely to be much of an update tomorrow, but it shouldn't be too long now before Hybrid has the same vocab as HW.... |
| ||
| New commmand for the day dxCaptureWorld() - Creates a 'snapshot' of all entities for later use with dxrenderworld's 'tweening'. This means of course that the dxrenderworld tween parameter now has a effect on an entity. If an entity has been 'captured' in the past and the dxrenderword tween value is not 1, a 'tween' state will be calculated for it. Please note, for the moment, only position, rotation and scale will be tweened. The rest (colour, alpha, shininess and all that) will follow. Please see dxcaptureworld.bb for an example. Numerous internal bugs have also been fixed. HW Should be more stable overall... |
| ||
| New collision functions dxCollisionX#(entity%,index%) - Returns the x world position of where collision n°index happens for an entity, or 0 if no collision or if collision index does not exist dxCollisionY#(entity%,index%) - Returns the y world position of where collision n°index happens for an entity, or 0 if no collision or if collision index does not exist dxCollisionZ#(entity%,index%) - Returns the z world position of where collision n°index happens for an entity, or 0 if no collision or if collision index does not exist dxCollisionNX#(entity%,index%) - Returns the x normal of collision n°index happens for an entity, or 0 if no collision or if collision index does not exist dxCollisionNY#(entity%,index%) - Returns the y normal of collision n°index happens for an entity, or 0 if no collision or if collision index does not exist dxCollisionNZ#(entity%,index%) - Returns the z normal of collision n°index happens for an entity, or 0 if no collision or if collision index does not exist dxCollisionSurface%(entity%,index%) - Returns the surface handle of collision n°index for an entity, or 0 if no collision or if collision index does not exist. Only works for polygon collisions. dxCollisionTriangle%(entity%,index%) - Returns the triangle index of collision n°index for an entity, or 0 if no collision or if collision index does not exist. Only works for polygon collisions. dxCollisionTime#(entity%,index%) - Returns the time taken for collision n°index for an entity, or 0 if no collision or if collision index does not exist. Please note - My collision routines are at present about 90% complete. All b3d collision routines now have their hardwired equivalent, but I have still yet to perfect the polygon collision routines, they almost work now - I just have to fine-tune it a bit. You will see what I mean if you switch to polygon collision mode in the dxcollisions.bb demo. The sphere and box collision methods however work at 100% (to my knowledge) and act exactly like thier b3d counterparts. |
| ||
|
New update out, my collision routines are nearing completion - they are
not at 100% quite yet but are taking shape - very good shape, see
dxcollisions.bb for a demo... Some parts of the collisions routines will not yet work, but should not crash either. The rest will follow, little by little for I now have the foundations of my colliision detection routines. The dxDebugHarsh routines have been improved. Any debug messages should now not precede a memory access violation and quit out immediately. A few new commands too.. dxCountCollisions%(entity%) - Return the number of collisions detected by last dxUpdateWorld command for a given entity. dxCollisionEntity%(entity%,index%) - Return the entity handle of the collision n°index detected using entity given in parameter or 0 if not found dxEntityCollided%(entity%,type%) - Return the entity handle of the collision type given in parameter for the entity given or 0 if not found dxCreateCone and dxCreateCylinder have now been updated to concur with b3d syntax and will now behave exactly like the b3d versions. |
| ||
| Have added a new instancer command... dxCopyInstancer%(instancer%) - Will completely make a copy of an instancer and return the copy's handle |
| ||
| New update - have fixed a texture freeing bug - a bug that was affecting amongst other things dxLoadTerrain. |
| ||
| New update out - dxPointEntity should now correctly function... |
| ||
| New update - have fixed a little scaling problem that caused inconsistency amongst other things with blitz3d's maths... |
| ||
| New update available - Shader init routines now updated for dx11 mode. Much faster than b4.... Other problems will have to wait for another day but I will work on them of course... Later... |
| ||
|
First worklog entry - I intend to continue to release all updates and
important news here, rather than on the threads. This will eliminate a
lot of the 'fluff' that only interest a certain amount of people.
Although I will take the time to read all the threads (sometimes
I'd even like to avoid reading some of them for some posts are complete
wastes of space and/or time), I can totally appreciate that some of you
would like to avoid having to read the threads and just get to the juicy
stuff. Releasing my updates on the worklog means that my posts will
effectively remain the last post in the thread all the time, so will not
be missed by anyone thinking I have not released anything new. I will
put a little notice on the blitz showcase forum for any new post on the
worklog. Ok, there is a new update out. This update contains no new commands, however there is a big increase in initailisation time. I have redesigned the shader init system of HW, so that the HW shaders are already compiled in the userlib and not compiled each time the dll is initialised. If you have a machine like mine, you should see a significant increase in speed. As always, any bugs let me know about them on the forum. I not saying I'll deal with them immediately but I'll note them. |