Community
Message Board

Chat room - users
Game Over
( 394431 downloads)
Work In Progress
( 523201 downloads)
Links

Code Exchange
Downloads
Tutorials
Add to Favourites

Submit news

DIV ARENA FORUMS
Not logged in [Login - Register]
Go To Bottom

Printable Version  
 Pages:  1  
Author: Subject: Tutorial?
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 18-12-2016 at 12:54 PM
Tutorial?


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.
View user's profile View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 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)
View user's profile View All Posts By User
tvault
DIV Newbie
*




Posts: 3
Registered: 18-12-2016
Member Is Offline


[*] posted on 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

View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 19-12-2016 at 12:59 PM


Hey Tvault, this is interesting. Thanks for posting.
View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 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?
View user's profile View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 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 :)
View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 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
View user's profile View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 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.
View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 21-12-2016 at 09:36 PM


well that got rid of that problem but I can't see a .so file, Help!
View user's profile View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 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?

View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 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
View user's profile View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 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


View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 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?
View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 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)?

View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 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]
View user's profile View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 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]
View user's profile View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 21-12-2016 at 10:31 PM


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

View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 22-12-2016 at 07:25 AM


Thanks dood. and merry Christmas
View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 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.
View user's profile View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 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.
View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 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 1744 times

View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 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]
View user's profile View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 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]
View user's profile View All Posts By User
dom cook
Div Pro
******




Posts: 386
Registered: 4-3-2016
Member Is Offline


[*] posted on 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]
View user's profile View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 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.
View user's profile View All Posts By User
 Pages:  1  

  Go To Top

Powered by XMB
XMB Forum Software © 2001-2012 The XMB Group
[Queries: 18]