DIV ARENA FORUMS

Tutorial?

dom cook - 18-12-2016 at 12:54 PM

Hey Mike,
Is there any chance of a tutorial on how to put together and use one of these DLL things?
My understanding of how it all works under the hood is zero and, to be honest, I'm seriously daunted at the thought of trying to figure it out myself so it would be great if you could make a basic walk-through with respect to getting things up and running,
I'd definitely like to start contributing more both with DLLs and the source code itself.

MikeDX - 18-12-2016 at 02:32 PM

DLLs are fairly straightforward regarding the compilation.

It's easy to compile the examples especially on Linux.

Clone the div source tree (not actually necessary as the dll code is seperate)

In tools there is a makedll.bat you can use to compile an example e.g.

tools/makedll.bat dll/hboy.c hboy.so


Should create a hboy.so "dll" which will autoload on any div program being run

Please forgive the accuracy of this info, I'm replying from my phone and going mostly on memory.

The examples are definitely the place to start but if you have specific questions I'm happy to help.

Also creating DLLs is definitely a "way in" to contributing to the main div codebase as quite a few functions started off as plugins and got integrated into the main codebase (network, mode8)

tvault - 18-12-2016 at 08:47 PM

Hi, I used DIV many years ago and decided to get back onboard as I always enjoyed using it.

If you're interested I found my copy of DIV and installed it using DOSbox, found a nice tutorial
from Daniel Navarro Medrano.

I hope this is useful to you:
Code:
DIV Games Studio - Dinamic Link Libraries ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ This document shows you all the needed information to build your own DLL's for DIV Games Studio - "What is a DLL?" A DLL (Dynamic Link Library) is a piece of code of a program that can be merged with another program in execution time, which contains functions or procedures that can be used on the program. - ¨What are DLL's for?" DLL's are useful to extend the programming language capabilities of DIV, so you can modify partially the way they work. These allow you to implement pieces of code in the C language, to be used or called from within DIV. - ¨Types of DLL's" Basically, there are three types of DLL's that can be built for DIV. The first ones are screen savers, the second are autoloading and the third ones add new functions to the language. General Instructions. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ This is procedure only recommended for EXPERT programmers on C language, who own the "WATCOM C++ Compiler". Other compilers are available, of course, but since we haven't tried them for this purpose, we cannot guarantee that they will work... First thing to do is add the following text to the WLSYSTEM.LNK file of Watcom (which can be found on the BINB\ directory of that compiler). system begin div_dll option osname='DIV DLL' libpath %WATCOM%\lib386 libpath %WATCOM%\lib386\dos format windows nt dll ^ end The format of the code used is the one of the Windows NT DLL's, and this is the way you inform Watcom to generate this kind of code. After this, you should include the header file named DIV.H, which is included on this directory. On this header file are the defined variables and basic functions with which you can use. In addition, this file contains a set of "#define" instructions, accessing the internal variables of DIV32RUN, which is the module that has all the internal functions and routines of DIV Games Studio. Several examples are included, the most basic being: DEMO0.CPP - Basic example of a screensaver with DIV's games. DEMO1.CPP - Basic example of an autoload DLL. DEMO2.CPP - Basic example of DLL functions. You may use the batch file named MAKE.BAT to compile these DLL's (if you own Watcom C++ for DOS) which, if no error is found, generates the corresponding DLL (with the same name). Basic rules. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ DLL's must be created in standard C, and they must respect several rules. For example: - The "div.h" header must be included on the main module, so the following definition must be done: #define GLOBALS before including the header (#include "div.h"), variables types and basic structures can be defined, this is for when you build DLL's with several CPP sources). - It is not possible to use the functions malloc(), free(), fopen() or fclose() so you must instead use div_malloc(), div_free(), div_fopen() and div_fclose(). These functions behave exactly the same way than the ones used on C. - You must always define two functions for the begin and end of the DLL, which are: void __export divmain(COMMON_PARAMS) { GLOBAL_IMPORT(); // Begin of DLL } void __export divend(COMMON_PARAMS) { // End of DLL } - Besides functions exported by DIV, you may use most standard C functions, including its headers. ¨How are DLL's used on the language?" ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ DLL's are divided on two types: normals and autoload. To use normals, you must indicate on a game the following sentence: IMPORT "directory\name.dll"; Just after the LOCAL declarations of the main program. You cannot use DLL's from other languages. Autoload can be used the same way, or just by copying them into the directory of the game. They will activate automatically. For example, if the DEMO0.DLL (the example screen saver) is copied on the directory of the game made with DIV, this will activate automatically every time the game is executed. To activate this DLL's while the game is executed within DIV's environment, you must copy them to the directory where the D.EXE (the main executable file of DIV) file is placed. Screen savers (look at demo0.cpp) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ You may define the following functions in a DLL. ss_init() - To initialize the screen saver (every time it is executed). ss_frame() - To make operations over the video buffer, before it is dumped. ss_end() - To terminate the screen saver. You have as well, the following available variables: ss_time - To indicate the period of time after which the screen saver will execute, on hundreds of a second (default is 3000, which is every 30 seconds). ss_status - To activate and deactivate the screen saver (0-Inactive/1-Active) ss_exit - It must be set to 1 on ss_frame() to terminate the screen saver (the system will set it to 1 when the keyboard, the mouse or the joystick is activated). A screen saver is included on the SS1.CPP file, which is a little bit more complex than the DEMO0.CPP. This simulates a sand picture. Autoload DLL (look at demo1.cpp) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ These DLL's are generally used to substitute some of the internal functions of DIV for another ones. The functions that can be defined are explained on the DIV.H file (under the "DIV standard Entry-Points" header). For a DLL to autoload, you must include the following sentence within the div_main() function: Autoload(); Two autoload DLL's are included as examples: WATER.CPP - Simulates a water effect on the bottom of the screen HBOY.CPP - Try it with any DIV game!... you will see... DLL of functions (look at demo2.cpp) ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ It is easy to add new functions to the language: First, you must create the new function on the DLL, which must read its calling parameters with getparm() (who always returns an int), and at termination, a value must ALWAYS be returned with retval() (look at demo2.cpp). After, you must define the function on the DLL: void __export divlibrary(LIBRARY_PARAMS) { } and within this, you must make a call to COM_export() for each function that is added to the language. COM_export() receives three parameters. The first one is the name that the function will have, the pointer to that function, and the number of parameters of the call. In the programs created with DIV, after making the IMPORT of the DLL, you may directly use these functions. ¨What can be done?" ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ If you take a look at DIV.H, you will find many things to which you may access from a DLL, you may create programs that modify variables of the process, that substitute video routines, or that apply effects in windows, etc... If you succeed to create a functional DLL, you are free to distribute it as Shareware or on any other format, even Freeware... which will be best! :) In any case, we will thank you, if you inform us, through the www.div-arena.com web site, about your personal success with DIV ;) We will also thank you any suggestion about DIV Games Studio, and much more if those suggestions are original and useful. Don't waste your time on asking us for sound modules, for 3D, or true colour....- we are already working on it!. ­ Thanks for trying! Daniel Navarro Medrano Main programmer of DIV Games Studio and from FastTrak Software Publishing


dom cook - 19-12-2016 at 12:59 PM

Hey Tvault, this is interesting. Thanks for posting.

dom cook - 21-12-2016 at 08:41 PM

Hi Mike
Just a quick question. I've just downloaded the source code and have started looking into this DLL business. I'm confused about the makedll file. In the tools folder there's a makedll.sh but not a makedll.bat as you stated is that the same thing?

MikeDX - 21-12-2016 at 08:49 PM

Yeah i was sure I'd named it .bat but it is the .sh file

Should work fairly easily

Let me know if you need any help :)

dom cook - 21-12-2016 at 08:52 PM

Quote: Originally posted by MikeDX  
Yeah i was sure I'd named it .bat but it is the .sh file

Should work fairly easily

Let me know if you need any help :)


I NEED HELP
I tried this:
tools/makedll.sh dll/hboy.c hboy.so

but got errors referring to the spectrum and sdlgfx folders in the dll one

MikeDX - 21-12-2016 at 09:09 PM

edit the last line in the file and change it to:

Code:
gcc $1 -o $2 -funsigned-char -shared -I./dll/ `sdl-config --cflags --libs` -ggdb3 -O3 -fPIC


It had been hardcoded to use my working directory and for zxspectrum dll / sdlgfx, neither of which you really need.

dom cook - 21-12-2016 at 09:36 PM

well that got rid of that problem but I can't see a .so file, Help!

MikeDX - 21-12-2016 at 09:40 PM

interesting

if you run the command manually what do you get

Code:
gcc dll/hboy.c -o hboy.so -funsigned-char -shared -I./dll/ `sdl-config --cflags --libs` -ggdb3 -O3 -fPIC ls *.so


any errors or warnings or anything?


dom cook - 21-12-2016 at 09:46 PM

/Desktop/DIV2015$ gcc dll/hboy.c -o hboy.so -funsigned-char -shared -I./dll/ `sdl-config --cflags --libs` -ggdb3 -O3 -fPIC
dll/hboy.c: In function ‘set_video_mode’:
dll/hboy.c:512:32: warning: passing argument 2 of ‘SDL_SetVideoMode’ makes pointer from integer without a cast [-Wint-conversion]
screen = SDL_SetVideoMode(320,200,8,0);
^
In file included from /usr/include/SDL/SDL_mouse.h:32:0,
from /usr/include/SDL/SDL_events.h:35,
from /usr/include/SDL/SDL.h:37,
from dll/hboy.c:8:
/usr/include/SDL/SDL_video.h:384:39: note: expected ‘int *’ but argument is of type ‘int’
extern DECLSPEC SDL_Surface * SDLCALL SDL_SetVideoMode
^
dll/hboy.c: In function ‘divmain’:
dll/hboy.c:697:29: warning: passing argument 2 of ‘SDL_SetVideoMode’ makes pointer from integer without a cast [-Wint-conversion]
screen=SDL_SetVideoMode(320,200,8,0);
^
In file included from /usr/include/SDL/SDL_mouse.h:32:0,
from /usr/include/SDL/SDL_events.h:35,
from /usr/include/SDL/SDL.h:37,
from dll/hboy.c:8:
/usr/include/SDL/SDL_video.h:384:39: note: expected ‘int *’ but argument is of type ‘int’
extern DECLSPEC SDL_Surface * SDLCALL SDL_SetVideoMode

MikeDX - 21-12-2016 at 09:48 PM

That looks fine to me

try it with errors ignored:

Code:
gcc dll/hboy.c -o hboy.so -w -funsigned-char -shared -I./dll/ `sdl-config --cflags --libs` -ggdb3 -O3 -fPIC



dom cook - 21-12-2016 at 09:50 PM

Hang on! the .so is there, it's in the parent folder. Sorry about that.
Where should it be placed in order to by included in a running prg?

dom cook - 21-12-2016 at 09:54 PM

Ok. Forget the last question. I managed to figure it out all on my own.
So It looks like everything is working now, Thanks for the help.
By the way how do you post code into a nifty little sub window in these forums (like you just did)?


dom cook - 21-12-2016 at 09:58 PM

And while I'm being a pain in the neck, do you think could you point me in the direction of the part of the source code which deals with mode 7? I'm interested to see the exact way DIV calculates the screen projections.

[Edited on 21-12-2016 by dom cook]

MikeDX - 21-12-2016 at 10:26 PM

Dom you know full well I am happy for you to be a pain in the neck :)


some DLLs are "autoload" which means they will automatically be picked up by DIV, this means put them in the same folder as your prg (or d.exe / d-LINUX / d-OSX etc). hboy is an example of such a dll.


to post code in a mini window use the code tags

e.g.
[code]
your code here
[/code]

I'm unsure about the mode7 in DIV, let me find that for you.


[Edited on 21-12-2016 by MikeDX]

MikeDX - 21-12-2016 at 10:31 PM

The Mode7 function is called 'pinta_m7' and is located in src/runtime/s.c


dom cook - 22-12-2016 at 07:25 AM

Thanks dood. and merry Christmas

dom cook - 22-12-2016 at 09:17 AM

I've think I've found a bug in mode 7 now

The x coordinate of the vanishing point in a screen region ought to be the midpoint in x of the region. This the case for mode7 objects but not for the plane that's declared in the start_mode 7 function. Instead it looks like it's using the midpoint (in x) of the whole screen.

MikeDX - 22-12-2016 at 09:40 AM

Interesting

I think you can prove or disprove this by making 4 mode 7 regions on a single screen with identical initial views.

dom cook - 22-12-2016 at 01:30 PM

Here's what I meant, although it seems I had it the wrong way round. It's the objects that focus on the centre of the screen.

This example should draw the object at point 0,0 on each of the m7 planes. (being the top-left corner)
By rotating the camera (keys _a, _d) you can see that it's being draw as if it lay on planes that were centred in x around the screen centre.

SNAP0001.PNG - 4kB

Attachment: m7bug.PRG (2kB)
This file has been downloaded 1745 times


dom cook - 11-5-2019 at 06:28 AM


It's only taken me two and a half years but I think I've found this little bug.

It's in the source code so I'm not in a position to fix it but now that you're making more time for DIV Mike, I thought I'd prevail upon you to take a look. Or Cictec if you're out there.

I might be wrong as I speak neither spanish nor C, but I think the problem is with Line 3057 here: https://github.com/MikeDX/DIV-Games-Studio/blob/master/src/r...


(3057) anchura = vga_an / 2 + (factor * distmax) / (max * 16);

As far as I can tell anchura is passed to the screen x coordinate of the M7 process.

vga_an looks like it refers to the size of a scan line. if that is the case then vga_an /2 is the middle of the screen in the x direction. In cases where mode 7 is drawn to a region whose centre in x is not the middle of the screen this will be the wrong value. The correct one being the x value for the middle of the mode 7 region.

Of course, this is admittedly all guess work and I realise that I might well be completely wrong but it at least corresponds with the error as illustrated in the above example.

Anyway, If one of you boys could take a look, I'd be much obliged.



[Edited on 11-5-2019 by dom cook]

CicTec - 11-5-2019 at 07:53 AM

Hi dom cook,

The line of the source code you are analyzing refers to the function that takes care of rendering mode7 processes (belonging to all mode7 windows) on the screen.

vga_an is a variable that stores the width of the game resolution set with SET_MODE, for example if you set the resolution to 640x480, vga_an will be 640 and vga_al will be 480 and so on, then 640/2 = 320 which represents the center of the resolution of the game.

it would be useful to mount a small example that shows the bug that you think exists.

[Edited on 11-5-2019 by CicTec]

dom cook - 11-5-2019 at 10:38 AM

I already did that. Look at the m7bug code 3 posts up from here.

It draws 4 mode7 views in 4 separate screen regions in a typical 4-way split-screen format.
If you rotate the views, using keys _A and _D you will see two red markers rotating around the centre of the screen.
These markers are actually the same mode 7 process drawn in the 4 separate views so we should be seeing 4 of them. Given that the coordinates of this process are 0,0 (Which corresponds to the top left corner of the mode 7 plane you can see that while the y coordinates are translated correctly, the x coordinates, are being translated as if the x_centres of all the m7 regions are always the x_centre of the screen.

So yes, in all likelihood vga_an is the culprit here. We need something that relates to individual screen regions. I don't know what that is going to be. However it's probably worth noting that, given that the y coordinate is being translated correctly, there might be a clue in the lines of code which deal with the corresponding altura variable.

Here is some pertinent code. (3045-3048)

Code:
h = (m7 + n)->height - mem[ide + _Height]; altura = (h * (max - factor)) / (max); // in pix/4 altura = im7[n].y + im7[n].al / 2 + (h - altura) / 4; // in pix altura += (m7 + n)->horizon - im7[n].al / 2;



I'm thinking that the variable n is probably the m7 number. Notably, there is no reference to this in the line which calculates the x coordinate.

Any ideas?

My best guess is that there's a variable out there called im7[n].an and subsituting it for vga_an in the alledged offending line might just help solve the problem. This would account for the width of the region, to account for its start position we might try im7[n].x
(we can already see that there is an im7[n].y)

My suggested correction would be this:

anchura = im7[n].x + im7[n].an/2 + (factor * distmax) / (max * 16);



[Edited on 11-5-2019 by dom cook]

CicTec - 11-5-2019 at 12:17 PM

Quote: Originally posted by dom cook  
I already did that. Look at the m7bug code 3 posts up from here.

It draws 4 mode7 views in 4 separate screen regions in a typical 4-way split-screen format.
If you rotate the views, using keys _A and _D you will see two red markers rotating around the centre of the screen.
These markers are actually the same mode 7 process drawn in the 4 separate views so we should be seeing 4 of them. Given that the coordinates of this process are 0,0 (Which corresponds to the top left corner of the mode 7 plane you can see that while the y coordinates are translated correctly, the x coordinates, are being translated as if the x_centres of all the m7 regions are always the x_centre of the screen.

Please post this example to be able to try and verify the actual presence of bugs

Quote: Originally posted by dom cook  

So yes, in all likelihood vga_an is the culprit here. We need something that relates to individual screen regions. I don't know what that is going to be. However it's probably worth noting that, given that the y coordinate is being translated correctly, there might be a clue in the lines of code which deal with the corresponding altura variable.

Based on the example above (to be tested with the real example), the culprit of the bug could be vga_an

Quote: Originally posted by dom cook  

Here is some pertinent code. (3045-3048)

Code:
h = (m7 + n)->height - mem[ide + _Height]; altura = (h * (max - factor)) / (max); // in pix/4 altura = im7[n].y + im7[n].al / 2 + (h - altura) / 4; // in pix altura += (m7 + n)->horizon - im7[n].al / 2;


I'm thinking that the variable n is probably the m7 number. Notably, there is no reference to this in the line which calculates the x coordinate.

Any ideas?

Yes, N is the variable that represents the mode7 number (of the window)

Quote: Originally posted by dom cook  

My best guess is that there's a variable out there called im7[n].an and subsituting it for vga_an in the alledged offending line might just help solve the problem. This would account for the width of the region, to account for its start position we might try im7[n].x
(we can already see that there is an im7[n].y)

My suggested correction would be this:

anchura = im7[n].x + im7[n].an/2 + (factor * distmax) / (max * 16);


[Edited on 11-5-2019 by dom cook]

The im7 structure is an internal structure that stores data when a request is made to create mode7 using the START_MODE7 function.

X y Y represent the coordinates where it starts on the screen (physical resolution chosen for the game) of the mode7 window.

AN y AL represent the widh y the height of the mode7 window, these 2 variables are updated based on what you pass in the "region" parameter of the START_MODE7 function, if you pass 0, they represent the width and height of the resolution (vga_an y vga_al), otherwise the width and the height of the region (for example we pass a region 1 previously defined with DEFINE_REGION of 300x300).

Based on what you have indicated, the modification of the code could be correct, please publish the example so as to be able to prove the result.

dom cook - 11-5-2019 at 01:21 PM

Publish the example, I don't know what you mean?
Do you mean for me to rewrite the line of source code and upload it to GitHub?

If you mean I should compile it, I'm afraid I haven't got a clue how to do that.

Or are you referring to the example which illustrates the issue? That's posted 5 posts up from here with a helpful screenshot.

Here's the code.

Code:
PROGRAM m7bug; GLOBAL ground_map; file1; map; ground_wide = 512; ground_high = 512; modex=800; modey=600; //------------------------------------------------------------------------------------- private i; BEGIN restore_type= no_restore; x=ground_wide/2; y=ground_high-32; mouse.x=100; mouse.y=100; map=makemap(); set_fps(60,0); //write_int(0,10,10,0,&fps); set_mode(800600); define_region(1,0,0,400,300); define_region(2,0,300,400,300); define_region(3,400,0,400,300); define_region(4,400,300,400,300); from i=1 to 4; start_mode7(i, file1, ground_map,0, i, 128+i*16); m7[i].height = 3210; m7[i].distance = 1144; m7[i].color = 210; m7[i].camera = map; m7[i].horizon =-200; m7[i].focus = 500; m7[i].z = 0; end marker(); END //---------------------------------------------- process marker(); begin graph=new_map(100,100,50,50,rand(0,255)); x=500; y=0; ctype=c_m7; loop frame; end end //--------------------------------------------------------------------------- PROCESS makemap() PRIVATE i; j; BEGIN ctype = c_m7; x=ground_wide/2; y=ground_high/2; //graph=3; angle=90000; ground_map =new_map(ground_wide,ground_high,ground_wide/2,ground_high/2,16*rand(0,14)); loop if(key(_a)) angle+=3000; end if(key(_d)) angle-=3000; end frame; end END //---------------------------------------------------------------------------


[Edited on 11-5-2019 by dom cook]

CicTec - 11-5-2019 at 01:43 PM

Quote: Originally posted by dom cook  

Or are you referring to the example which illustrates the issue? That's posted 5 posts up from here with a helpful screenshot.

Here's the code.

Code:
PROGRAM m7bug; GLOBAL ground_map; file1; map; ground_wide = 512; ground_high = 512; modex=800; modey=600; //------------------------------------------------------------------------------------- private i; BEGIN restore_type= no_restore; x=ground_wide/2; y=ground_high-32; mouse.x=100; mouse.y=100; map=makemap(); set_fps(60,0); //write_int(0,10,10,0,&fps); set_mode(800600); define_region(1,0,0,400,300); define_region(2,0,300,400,300); define_region(3,400,0,400,300); define_region(4,400,300,400,300); from i=1 to 4; start_mode7(i, file1, ground_map,0, i, 128+i*16); m7[i].height = 3210; m7[i].distance = 1144; m7[i].color = 210; m7[i].camera = map; m7[i].horizon =-200; m7[i].focus = 500; m7[i].z = 0; end marker(); END //---------------------------------------------- process marker(); begin graph=new_map(100,100,50,50,rand(0,255)); x=500; y=0; ctype=c_m7; loop frame; end end //--------------------------------------------------------------------------- PROCESS makemap() PRIVATE i; j; BEGIN ctype = c_m7; x=ground_wide/2; y=ground_high/2; //graph=3; angle=90000; ground_map =new_map(ground_wide,ground_high,ground_wide/2,ground_high/2,16*rand(0,14)); loop if(key(_a)) angle+=3000; end if(key(_d)) angle-=3000; end frame; end END //---------------------------------------------------------------------------


[Edited on 11-5-2019 by dom cook]

exactly that :), later I try it and let you know

CicTec - 12-5-2019 at 11:10 AM

Ok, i've tested and yes, the bug is what you have indicated and the fix code the same, now hotpoint rotates together with the figure remaining always in the tip, here the screenshot:
DIVDX_mode7_bug_fixed.png - 7kB

Congratulations for having found the bug without knowledge in C. :)



dom cook - 12-5-2019 at 06:23 PM

That's great. Thanks for sorting that out. To be honest though, I do have knowledge of C. I used it in a project about 15 years ago. It's just that I just wouldn't be able to write anything in it these days. But reading and writing are two different things. It's the same with Spanish.

So now, how would I go about getting the fixed version? Will there be a new build or something?


CicTec - 12-5-2019 at 06:33 PM

Quote: Originally posted by dom cook  
That's great. Thanks for sorting that out. To be honest though, I do have knowledge of C. I used it in a project about 15 years ago. It's just that I just wouldn't be able to write anything in it these days. But reading and writing are two different things. It's the same with Spanish.

You are welcome. :)

it is good to have knowledge in C, even if minimal. :)

Quote: Originally posted by dom cook  

So now, how would I go about getting the fixed version? Will there be a new build or something?

This is a bit of a problem at present, unfortunately my current PC has problems with the latest versions of windows 10 due to video driver issues, so I had to switch to Linux and have no form when it comes to generating builds for windows in a simple way or to test them (I should start windows, hoping that it doesn't crash, but if it happens I have to manually turn off the machine and risk damage to the disk, etc ...).

Furthermore the current official repository does not contain all the latest fixes made by me with the latest build generated (over 40 bugs).

The best solution would be at the moment if you can install the compilation environment, download the latest code from my repository, fix the mode7 yourself (or maybe I upload the fix in the repository) and then generate the build yourself.

If you tell me which operating system you are using I can give you a hand with installing the development environment.

dom cook - 12-5-2019 at 07:05 PM

As things stand I'm borrowing my wife's laptop when it's free. I have a desktop folder on it with all my stuff in it but I can't really take it over and start installing stuff. I've been meaning to get my own computer for the last 3 years but have just never got around to it However it's now looking like I'm going to have to bite the bullet and get one. I know you suggested Linux to me in the past so I 'll look to getting one of those.

My next question is, do you have any suggestions about make or specs? The easiest thing would be for me to order one from Dell. Is that a bad idea?

CicTec - 12-5-2019 at 07:26 PM

Quote: Originally posted by dom cook  
As things stand I'm borrowing my wife's laptop when it's free. I have a desktop folder on it with all my stuff in it but I can't really take it over and start installing stuff. I've been meaning to get my own computer for the last 3 years but have just never got around to it However it's now looking like I'm going to have to bite the bullet and get one.

Yes, I understand you, maybe now it's a good excuse to take the new PC. ;)

Quote: Originally posted by dom cook  

I know you suggested Linux to me in the past so I 'll look to getting one of those.

In reality I had suggested Windows, being the most used operating system in terms of game development and game engine, it was Mike who suggested you Linux.

Quote: Originally posted by dom cook  

My next question is, do you have any suggestions about make or specs? The easiest thing would be for me to order one from Dell. Is that a bad idea?

If we talk about hardware specifications for the new PC and a complete set-up for developing your games and working with DIV (even just generating builds for fixes and testing), my suggestions are these:
- CPU at least of an Intel i5 at 2.8ghz, better with integrated intel GPU (although now all models have this).
- at least 16GB of RAM
- discrete video card (preferably NVIDIA) with at least 8GB of ram (there are many models, let's say a version within your pocket with good performances for 3D).
- 250GB SSD disk for installing windows 10 (possibly PRO version) and some programs (including the development environment).
- 1GB HDD disk (Western Digital advice) for Linux distro installation (in order to have more operating systems) to be partitioned, a 500GB for use of 2 Linux distro and 500GB for any virtualized versions.
- 1GB HDD disk with external box for all your data and more (I recommend making periodic backups at least every 10-15 days).

With this you should be able to fit everything you need.

dom cook - 12-5-2019 at 07:50 PM

Ok Thanks, I'll start looking.

CicTec - 12-5-2019 at 08:07 PM

You're welcome.

You could also try on amazon, there are many offers and lower prices compared to other parts for many things (even if it depends a lot on the country), if you are also an assembly expert you could buy the separate pieces and mount the PC yourself.

dom cook - 20-4-2021 at 11:18 AM

I am delighted to proclaim that I have only done it. Armed only with my trusty new Raspberry Pi and a cheat sheet from Mike, I built DIV with this bug fixed. Big Win! Thanks Mike. (and CicTec if you're still around)
Here's my screenshot.


sct.jpg - 10kB

The problem now is that I can't remember why I needed this fix in the first place. I'm sure I had an amazing game planned.

[Edited on 20-4-2021 by dom cook]

(Not sure what's up with the screenshot..





[Edited on 20-4-2021 by dom cook]

sct.png - 72kB

CicTec - 20-4-2021 at 11:38 AM

Hi dom cook,

Congratulations on being able to build the DIVDX build from the source code. :)

Are you referring to the above mode7 bug?

dom cook - 20-4-2021 at 12:01 PM

That is right. I know you did this already, but I never got around to it myself. My computer broke and it took a while to get a new one (raspberry pi) and an even longer time to start using it. Mike showed me how to download and build DIV for it. Fortunately, this thread was still up so I just cut and pasted the code that you had already confirmed worked, so thanks for that.
I guess this might mean that I'm in a position to help with fixing DIV if there's anyone out there with a vision for this.

CicTec - 20-4-2021 at 12:09 PM

Sounds great to me. :)

Yes, I had fixed the bug, but I don't remember if I had inserted the fix in the DIV fork repository that I had made for development.

dom cook - 20-4-2021 at 12:16 PM

I didn't think there had been too much development over the last couple of years. Have you done much with your DIV fork?

CicTec - 20-4-2021 at 05:28 PM

Currently not, I am using the free time available to follow with my own DIV engine that I have been developing for years, if I can get more time I will continue something and publish it.

However, you can find everything developed so far here:
https://github.com/CicTec/DIV-Games-Studio

This version contains many bugfixes and is more up to date than the official repository version, if you are interested you can download it to generate a DIVDX build for you.

dom cook - 20-4-2021 at 06:34 PM

Quote: Originally posted by CicTec  
Currently not, I am using the free time available to follow with my own DIV engine that I have been developing for years, if I can get more time I will continue something and publish it.


However, you can find everything developed so far here:
https://github.com/CicTec/DIV-Games-Studio

This version contains many bugfixes and is more up to date than the official repository version, if you are interested you can download it to generate a DIVDX build for you.



Thanks. I'll give it a go. Good luck with your own engine, I hope to see it one day. The more versions of DIV the merrier.

CicTec - 20-4-2021 at 06:37 PM

Thanks, The engine has already been available for public use for many years and is used by several DIV users.

dom cook - 21-4-2021 at 04:17 AM

I see. Gemix?

CicTec - 21-4-2021 at 05:10 AM

Yes.