Welcome!
Final Burn Neo => FBN Development => Topic started by: KOF2112 on August 07, 2008, 03:50:06 PM
-
http://www.barryharris.me.uk/index.php
v0.2.96.91
- Added the 2xPM filter to the softfx filters with help from Captain CPS-X
- Added ElSemi's SuperScale and SuperScale75 filters
- Made the IPS Manager fallback to Simplified Chinese as a last resort as
this is the reference language for the MAME Plus IPS collection
- Made the IPS Manager description vertically scrollable for long
descriptions and reorganised the dialog
- Added Captain CPS-X's auto monitor aspect ratio code
- Added driver for Unico games
- Moved the drawing code in CPS-1/CPS-2 to happen after the VBLANK IRQ -
this shouldn't cause any problems but if you see anything that didn't
happen in previous builds let us know
-
Cual es la mejor configuracion que puedo poner el emulador?
What is the best configuration?
-
Nice timing ^^, I just finished working on something Barry needed :biggrin:
Expect something in a couple of mins :wink:
SeeYaa!
:biggrin:
-
Kaillera Client feature for FB Alpha v0.2.96.91
Here it is! Kaillera update for the latest FB Alpha, you don't neccessary need the DLL to use the emulator, and if you like to play online just use the included 'kailleraclient.dll' v0.9 with support of Windows XP Theme! ^^ No more invisible areas in the netplay window :biggrin:
I did a package including all the modded files ready to go, so you only have to replace the old source files and compile. There is a TXT file inside with step-by-step instructions to manually add kaillera support to FBA if you don't wanna overwrite your source for some reason :smilie:
Enjoy! and if anyone have issues adding the feature please let me know ^^
SeeYaa!
:biggrin:
-
It'd be better if it was dynamically loaded and initialized inside and then freed up inside DoNetGame. It'd save wasting unneeded resources in presence of the kailleraclient.dll. There were some other issues too with the netplay implementation the last time around which was carried onto this patch. I don't mind posting a patch to that later in the day when I'm home but still...kaillera is outdated.
Edit: also: latest version of nfba based on the last version: http://kaillera.movsq.net/old/nfbadtrcfull.7z You should be able to use it's netplay with http://okai.movsq.net/wip/n02.dll
I don't fully understand what you mean by 'dinamically loaded', but anyway, I posted that update to re-enable the support of kaillera, BUT making it possible to launch FBA without the 'dll', that way giving the user the liberty of using FBA for netplay or for normal play. The reason kaillera was removed from FBA was because the emu itself was depending on the file to work, so Barry then decided to remove it completely.
btw, this update was requested by Barry (Treble Winner) and I was glad to help him out ^^, he told me other things he had in mind but that's not public and i will not ruin his future surprises :p
I'll keep giving support to the official build of FBA like I have always done because its the big thing and because its the original, not like the other crappy closed source builds around the net (I hope this doesn't hurt anyone's feelings xD). There will be a day when the users will have everything they need in only one nice and clean official build.
SeeYaa!
:biggrin:
-
I don't fully understand what you mean by 'dinamically loaded', but anyway, I posted that update to re-enable the support of kaillera, BUT making it possible to launch FBA without the 'dll', that way giving the user the liberty of using FBA for netplay or for normal play. The reason kaillera was removed from FBA was because the emu itself was depending on the file to work, so Barry then decided to remove it completely.
btw, this update was requested by Barry (Treble Winner) and I was glad to help him out ^^, he told me other things he had in mind but that's not public and i will not ruin his future surprises :p
I'll keep giving support to the official build of FBA like I have always done because its the big thing and because its the original, not like the other crappy closed source builds around the net (I hope this doesn't hurt anyone's feelings xD). There will be a day when the users will have everything they need in only one nice and clean official build.
SeeYaa!
:biggrin:
Think you misunderstood me. Just lost interest so nvm.
-
Think you misunderstood me. Just lost interest so nvm.
no problem... [?]...I said clearly that I didn't understand what you mean by 'dynamically loaded'... hoping you may explain a little more but no problem if you just lost interest ^^U
BTW, the stuff I wrote about 'crappy closed source builds' wasn't refering to your build xD, you release the source everytime so there is no issue :p
If what I say seems a bit strange is because my original language is Spanish so sorry if I said something wrong :redface:
Finally, Im gonna test a modification I made to be able to select the Kaillera Client DLL from anywhere on the PC and save the path into the fba.ini, if everything goes right i will post the code here too ^^
SeeYaa!
:biggrin:
-
Kaillera Client feature for FB Alpha v0.2.96.91
Here it is! Kaillera update for the latest FB Alpha, you don't neccessary need the DLL to use the emulator, and if you like to play online just use the included 'kailleraclient.dll' v0.9 with support of Windows XP Theme! ^^ No more invisible areas in the netplay window :biggrin:
I did a package including all the modded files ready to go, so you only have to replace the old source files and compile. There is a TXT file inside with step-by-step instructions to manually add kaillera support to FBA if you don't wanna overwrite your source for some reason :smilie:
Enjoy! and if anyone have issues adding the feature please let me know ^^
SeeYaa!
:biggrin:
Awesome！Thx Captain :biggrin:
-
Compiling src/interface/2xpm.cpp...
src/interface/2xpm.cpp: In function `void _2xpm_1516(void*, void*, long
unsigned int, long unsigned int, long unsigned int, long unsigned int, int)
':
src/interface/2xpm.cpp:81: warning: unused parameter `int depth'
Compiling src/burn/burn.cpp...
intentional?
-
intentional?
Use the official release - I tidied the warning already.
-
It'd be better if it was dynamically loaded and initialized inside and then freed up inside DoNetGame. It'd save wasting unneeded resources in presence of the kailleraclient.dll. There were some other issues too with the netplay implementation the last time around which was carried onto this patch. I don't mind posting a patch to that later in the day when I'm home but still...kaillera is outdated.
Edit: also: latest version of nfba based on the last version: http://kaillera.movsq.net/old/nfbadtrcfull.7z You should be able to use it's netplay with http://okai.movsq.net/wip/n02.dll
I'm not particuarly well-versed on netplay at all - if someone wants to volunteer to do it properly (using kaillera or whatever else is out there currently) in the official tree then please volunteer. :) The only stipulation I will make is that the emulator should not need a dll to be present in order to run normally, nor should it include any netplay library as an object. Anyone up for it?
-
FB Alpha v0.2.96.91 - NeoSource Download Mirrors
I updated the FB Alpha collection available here at NeoSource with the latest releases of both Source and Binary, here are the direct downloads:
fba_src_029691.zip (http://fightercore.plesk3.freepgs.com/files/neosource/fba/fba_src_029691.zip) [~2.87MB][Source]
fba_029691.zip (http://fightercore.plesk3.freepgs.com/files/neosource/fba/fba_029691.zip) [~2.22MB][Unicode Binary]
FinalBurn Alpha Download Checkpoint -> http://neo-source.com/index.php?topic=832.0
SeeYaa!
:biggrin:
-
2xPM in FBA use HQ or LQ mode?
PS:
preview pack full: http://www.emu-france.com/?page=fichiers&idFile=1422
titles pack full: http://www.emu-france.com/?page=fichiers&idFile=1914
:)
-
Kaillera Client feature for FB Alpha v0.2.96.91
Here it is! Kaillera update for the latest FB Alpha, you don't neccessary need the DLL to use the emulator, and if you like to play online just use the included 'kailleraclient.dll' v0.9 with support of Windows XP Theme! ^^ No more invisible areas in the netplay window :biggrin:
I did a package including all the modded files ready to go, so you only have to replace the old source files and compile. There is a TXT file inside with step-by-step instructions to manually add kaillera support to FBA if you don't wanna overwrite your source for some reason :smilie:
Enjoy! and if anyone have issues adding the feature please let me know ^^
SeeYaa!
:biggrin:
Thanks for that Captain. For some reason the menu item isn't available for me here? It just plain isn't shown.
-
Thanks for that Captain. For some reason the menu item isn't available for me here? It just plain isn't shown.
Seem to have corrected it by moving the menuitem down below the most recently used games entry - weird.
Edit - now works in the original place - I must have done something daft! Captain's code is in - if anyone wants to expand on netplay as I said earlier please let us know.
-
I would be very happy if netplay returned in the official builds :)
-
Use the official release - I tidied the warning already.
You mean the one from your site? I did but I'm still getting the same warning, and now a clock skew warning which sounds like my fault but I haven't learned how to fix that yet. :redface:
-
You mean the one from your site? I did but I'm still getting the same warning, and now a clock skew warning which sounds like my fault but I haven't learned how to fix that yet. :redface:
Seems I missed that one actually - I got the other two. It's harmless anyway and fixed in my build now.
-
no problem... [?]...I said clearly that I didn't understand what you mean by 'dynamically loaded'... hoping you may explain a little more but no problem if you just lost interest ^^U
BTW, the stuff I wrote about 'crappy closed source builds' wasn't refering to your build xD, you release the source everytime so there is no issue :p
Finally, Im gonna test a modification I made to be able to select the Kaillera Client DLL from anywhere on the PC and save the path into the fba.ini, if everything goes right i will post the code here too ^^
SeeYaa!
:biggrin:
(Basically . . ) Dynamic loading means you use LoadLibaray instead of statically linking the .dll/.lib to the exe. I thought that the initial kallieria build of fba had dynamic loading but I can't find an example. MSDN has some stuff: http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms686944(VS.85).aspx
-
I'm not particuarly well-versed on netplay at all - if someone wants to volunteer to do it properly (using kaillera or whatever else is out there currently) in the official tree then please volunteer. :) The only stipulation I will make is that the emulator should not need a dll to be present in order to run normally, nor should it include any netplay library as an object. Anyone up for it?
Didn't mean to offend anyone in any way. Those things are a result of lack of documentation on Official kaillera's parts.
In Captain CPS-X's language... what I meant was something relocating Init_Network and Kaillera_Shutdown(); call from AppInit/Kaillera_Shutdown(); to DoNetGame. From what I can remember from the top of my head...among others were replacing inputs with default input when kailleraModifyPlayValues returns 0... and there were a few things that makes some drivers less deterministic during netplay e.g. some settings like using the c core instead of asm or the 60hz refresh rate etc... They aren't big deals. Worthless sprouts of some newb who spent too much time with kaillera. Statistically, FBA being used for netplay directly is extremely rare so it doesn't matter =)
-
(Basically . . ) Dynamic loading means you use LoadLibaray instead of statically linking the .dll/.lib to the exe. I thought that the initial kallieria build of fba had dynamic loading but I can't find an example. MSDN has some stuff: http://msdn.microsoft.com/en-us/library/ms684175(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms686944(VS.85).aspx
Ohhh! I see, thanX KEV ^^! Well in the code I posted it's using Dynamic Loading it seems because I compared codes from MSDN and its basically the same thing, check this from 'src\kaillera\client\net.cpp'
int Init_Network(void)
{
Kaillera_HDLL = LoadLibrary("kailleraclient.dll");
if (Kaillera_HDLL != NULL)
{
Kaillera_Get_Version = (int (WINAPI *)(char *version)) GetProcAddress(Kaillera_HDLL, "_kailleraGetVersion@4");
Kaillera_Init = (int (WINAPI *)()) GetProcAddress(Kaillera_HDLL, "_kailleraInit@0");
Kaillera_Shutdown = (int (WINAPI *)()) GetProcAddress(Kaillera_HDLL, "_kailleraShutdown@0");
Kaillera_Set_Infos = (int (WINAPI *)(kailleraInfos *infos)) GetProcAddress(Kaillera_HDLL, "_kailleraSetInfos@4");
Kaillera_Select_Server_Dialog = (int (WINAPI *)(HWND parent)) GetProcAddress(Kaillera_HDLL, "_kailleraSelectServerDialog@4");
Kaillera_Modify_Play_Values = (int (WINAPI *)(void *values, int size)) GetProcAddress(Kaillera_HDLL, "_kailleraModifyPlayValues@8");
Kaillera_Chat_Send = (int (WINAPI *)(char *text)) GetProcAddress(Kaillera_HDLL, "_kailleraChatSend@4");
Kaillera_End_Game = (int (WINAPI *)()) GetProcAddress(Kaillera_HDLL, "_kailleraEndGame@0");
if ((Kaillera_Get_Version != NULL) && (Kaillera_Init != NULL) && (Kaillera_Shutdown != NULL) && (Kaillera_Set_Infos != NULL) && (Kaillera_Select_Server_Dialog != NULL) && (Kaillera_Modify_Play_Values != NULL) && (Kaillera_Chat_Send != NULL) && (Kaillera_End_Game != NULL))
{
Kaillera_Init();
Kaillera_Initialised = 1;
return 0;
}
FreeLibrary(Kaillera_HDLL);
} else {
}
Kaillera_Get_Version = Empty_Kaillera_Get_Version;
Kaillera_Init = Empty_Kaillera_Init;
Kaillera_Shutdown = Empty_Kaillera_Shutdown;
Kaillera_Set_Infos = Empty_Kaillera_Set_Infos;
Kaillera_Select_Server_Dialog = Empty_Kaillera_Select_Server_Dialog;
Kaillera_Modify_Play_Values = Empty_Kaillera_Modify_Play_Values;
Kaillera_Chat_Send = Empty_Kaillera_Chat_Send;
Kaillera_End_Game = Empty_Kaillera_End_Game;
Kaillera_Initialised = 0;
return 1;
}
So I think everything is cool, right? :biggrin:
SeeYaa!
:biggrin:
-
Ohhh! I see, thanX KEV ^^! Well in the code I posted it's using Dynamic Loading it seems because I compared codes from MSDN and its basically the same thing, check this from 'src\kaillera\client\net.cpp'
So I think everything is cool, right? :biggrin:
SeeYaa!
:biggrin:
Yup - it is dynamically linked. I moved the calls as recommended by 0746 though - extract the attached into ./src/burner/win32.
The difference now is that the library is only loaded when starting a netgame, and is killed straight after closing the game - keeps resources free when they're not needed.
-
Yup - it is dynamically linked. I moved the calls as recommended by 0746 though - extract the attached into ./src/burner/win32.
The difference now is that the library is only loaded when starting a netgame, and is killed straight after closing the game - keeps resources free when they're not needed.
Cool! ^^ I've tested it and works perfectly :cool:
btw, there is a little thing that needs to be edited in 'scrn.cpp' ^^U (I was the one who wrote the message stuff so I feel responsible for it xD)...
FIND THIS >>>>
MessageBox(hScrnWnd, _T("You need the KAILLERACLIENT.DLL file in order to use this feature. You will need to restart FBA after placing the DLL."), _T("FB Alpha Info"), MB_OK);
REPLACE WITH >>>>
MessageBox(hScrnWnd, _T("You need the 'kailleraclient.dll' file in order to use this feature."), _T("FB Alpha Info"), MB_OK);
The new message looks better and with the final modifications that you made there is no need for the user to restart FBA after placing the dll in the directory. :biggrin:
PS: I modified the 'scrn.cpp' file myself with this little text update so you don't really have to bother editing it again ^^, it's attached :wink:
SeeYaa!
:biggrin:
-
I'm not particuarly well-versed on netplay at all - if someone wants to volunteer to do it properly (using kaillera or whatever else is out there currently) in the official tree then please volunteer. :) The only stipulation I will make is that the emulator should not need a dll to be present in order to run normally, nor should it include any netplay library as an object. Anyone up for it?
I don't think I'd be up for it ^_^ The type of enhancements I'm doing i.e. working with savestates which includes stuff normal savestates shouldn't contain and using them to run the gameplay at couple of times its normal speed to send input values back and forth emulation for the purpose of hiding network latency i.e. making a total mess out of FBA sources and breaking lots of emulation correctness...is just unsuitable for official FBA =)
-
Cool! ^^ I've tested it and works perfectly :cool:
btw, there is a little thing that needs to be edited in 'scrn.cpp' ^^U (I was the one who wrote the message stuff so I feel responsible for it xD)...
FIND THIS >>>>
REPLACE WITH >>>>
The new message looks better and with the final modifications that you made there is no need for the user to restart FBA after placing the dll in the directory. :biggrin:
PS: I modified the 'scrn.cpp' file myself with this little text update so you don't really have to bother editing it again ^^, it's attached :wink:
SeeYaa!
:biggrin:
Thanks - I've changed it to a string resource so it can be localised.
-
Hey Barry I started doing a research on how to implement a simple way to get files from a URL and save them to a specified directory and found a nice way to do it (haven't tried yet), you may be wondering why, and well I was thinking about a feature that when FBA looks for the preview/title/cabinet/etc of a game if the file is not present on the configured dirs it will download the needed image from a specific server, like for example : http_//fightercore.plesk3.freepgs.com/files/neosource/fba/support/titles/mvsc.png
If this feature works like I think it does, then probably it can be implemented to check for FBA updates too, like for example, downloading a temporary txt file then opening it to check the string inside for example: release_029691 and do further operations.
I just wanted to know if you like the idea so I can keep working on this or if you don't think this is good, anyway let me know what u think ^^
SeeYaa!
:biggrin:
-
I like the idea - it's just the bandwidth usage that worries me!
I've had an idea for a MAME front-end for a long-time. It would be a web-site that is navigated by the user and MAME is launched by clicking a link. This has the advantage of being cross-platform and the user would never have to update resource files.
I had even wrote a quick little browser that got around the issue of prompting and not allowing exes to run from a browser as a proof of concept. All it would need is one of these browsers for each OS that wanted to run it.
Anyway, I ramble - the point I'm making is that I never did it due to bandwidth worries. I would be very interested in your idea if we can address the bandwidth.
-
If a particular file is not available locally, then the downloading thing could download that file to that spot. This way you're caching the file you've downloaded and won't need to download it again. This sounds like a really great idea CaptainCPS-X =) The files on wherever they're hosted could be compressed as well to save extra bandwidth.
It's also possible to implement something like a central repository type things to for the automatic update thing you are talking about. If someone wrote an update script, think it'd go really well.
-
If a particular file is not available locally, then the downloading thing could download that file to that spot. This way you're caching the file you've downloaded and won't need to download it again. This sounds like a really great idea CaptainCPS-X =) The files on wherever they're hosted could be compressed as well to save extra bandwidth.
It's also possible to implement something like a central repository type things to for the automatic update thing you are talking about. If someone wrote an update script, think it'd go really well.
My concern though is 50000 people downloading 2000 flyers, 2000 titles, 2000 previews, etc. You get the idea. :) Even if they only download once it's still a fair bit of bandwidth.
-
If a particular file is not available locally, then the downloading thing could download that file to that spot. This way you're caching the file you've downloaded and won't need to download it again. This sounds like a really great idea CaptainCPS-X =) The files on wherever they're hosted could be compressed as well to save extra bandwidth.
It's also possible to implement something like a central repository type things to for the automatic update thing you are talking about. If someone wrote an update script, think it'd go really well.
0746: Would a customised version of okai_p2pchat or something allow flyers, etc to be distributed p2p? Not sure how workable that would be, but it would be interesting to try.
-
Kev: Sorry the name seems to be a little bit misleading there ^_^. okai_p2pchat is IRC an extension for the p2p client.
But still, we are talking about thousands of files here. With the distributed p2p approach, the gravest issue will be users having to be present online ready to upload. I can't imagine many being happy about it. When a few people who are willing to keep sharing loose interest, which happens more often than not, people will be unable to retrieve files.
My concern though is 50000 people downloading 2000 flyers, 2000 titles, 2000 previews, etc. You get the idea. :) Even if they only download once it's still a fair bit of bandwidth.
The only other thing I can think of is if we put up multiple repositories in different places instead of a central one so that the load can be spread across repositories. I think this is the most common solution to this problem. For example steam content servers...linux repositories...sourceforge.net files etc. But this also brings up the issue of everyone having to keep their content up to date.
-
My concern though is 50000 people downloading 2000 flyers, 2000 titles, 2000 previews, etc. You get the idea. :) Even if they only download once it's still a fair bit of bandwidth.
Well I can at least offer my server for this ^^, I was checking my control panel and it say this "The amount of bandwidth used by a client: 0 B of unlimited traffic used" xDD lol
I will put it to the test to see if its really unlimited hehe :p, the thing i still need to check is if I can upload everything there, I will check how much space does images/cabinets/flyers/etc require and if my available space is able to handle it, I hope it does xD
Oh!, and ThanX for the responses and comments everyone!
SeeYaa!
:biggrin:
-
I can also host a repository if you guys decide to have multiple ones. I still have more than 5 gigs of free space and get about 70ish gb unused quota every month. The only limitation I have is no of files. Still can manage around 10000 thou.
-
I have a full collection of full-size previews - that is 18.2MB.
-
I have a full collection of full-size previews - that is 18.2MB.
That is compressed or uncompressed ? sounds good if it's uncompressed ^^
btw, I have news about the feature!, I managed to do a very simplified function to download a file to a specified location using WinInet API, this library is very good and compatible with different compilers, at first I was trying a shorter path using 'urlmon.lib and urlmon.h' but those are exclusively in Microsoft SDK and not portable to MinGW.
So here is a preview of what i have right now, note that the url and save path will be replaced with variables in the final version
// Very simple function to download a file using WinInet API
void FileDownload()
{
HINTERNET url, open;
TCHAR URL_LOCATION[512] = _T("http://fightercore.plesk3.freepgs.com/files/neosource/fba/splash.bmp");
TCHAR final_file_name[512] = _T("C:\\sample.bmp");
if(URL_LOCATION == NULL) {
// Error managing code goes here
}
open = InternetOpen(_T("ExampleDL"), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0);
url = InternetOpenUrl(open, URL_LOCATION, NULL, 0, 0, 0);
FILE *saved;
DWORD buffer;
TCHAR name[128];
saved = _tfopen(final_file_name, _T("wb"));
while(InternetReadFile(url, name, sizeof(name), &buffer) && buffer != 0) {
fwrite(name, 1, buffer, saved);
name[buffer] = _T('\0');
}
fclose(saved);
}
SeeYaa!
:biggrin:
-
Hey Barry! I have done a more elaborated module to download the image files and its looking good so far ^^, it doesn't take too long to load a image, what I have to do now is a modification to the module so it knows the type of image is looking for, like for example: title / flyer / cabinet / etc, but that should not be a big issue
If you can upload the preview package you have to rapidshare or other kind of file hosting I will appreciate it a lot ^^, for now Im gonna use some previews i have here to keep testing in my server :smilie:
ThanX in advance!
I attached the module as it is by now, so you can check it out while I keep working on it, suggestions are welcome =)
SeeYaa!
:biggrin:
-
:eek: In which version was the "slider, speed, center" code added for games with configurations of Left/Right, Up/Down & Throttle?
I either must've missed this or it's always been there, but I never knew how to configure a racing wheel/flight stick game until I saw this code as default in a game's input today. Thanks for that because these type of configurations always puzzled me!
-
That looks nice Captain =) Give us a buzz if that WinINet stuff doesn't work out. I'll write you a winsock version in 20 minutes =)
18mb compressed doesn't sound that much =) It'll be 40-50ish mb max when uncompressed.
-
Here it is my latest update to what I have by now of the Image download feature im working, later after I get some rest I will keep updating it to work more accurate, check 'TODO' comments to see some of the stuff I have to work on :smilie:
If anyone wanna take a look of the code, get the main module cpp from the attachment ;p, I commented the code for better understanding of what each part does, and if anyone is learning programming it may help ^^.
EDIT: If somebody is wondering why I wrote the file checking, its because Apache servers (at least the one hosting my things) display a default HTML document if a file is not found for any reason, most of the servers have this feature on and that doesn't work like a normal redirection, so WinInit API will not know if the data received from that URL is the right one or if its a error document. Btw, if the connection is not successful to a server then nothing is transferred and there is no problem, the only problem I was having was the mentioned before.
EDIT2: Here you have some examples of data that is transfered in place of a file that is not found on the server...
http://neosource.1emu.net/lala
<HTML>
<HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD>
<BODY>
<H1>Not Found</H1>
The requested document was not found on this server.
<P>
<HR>
<ADDRESS>
Web Server at 1emulation.com
</ADDRESS>
</BODY>
</HTML>
<!--
- Unfortunately, Microsoft has added a clever new
- "feature" to Internet Explorer. If the text of
- an error's message is "too small", specifically
- less than 512 bytes, Internet Explorer returns
- its own error message. You can turn that off,
- but it's pretty tricky to find switch called
- "smart error messages". That means, of course,
- that short error messages are censored by default.
- IIS always returns error messages that are long
- enough to make Internet Explorer happy. The
- workaround is pretty simple: pad the error
- message with a big comment like this to push it
- over the five hundred and twelve bytes minimum.
- Of course, that's exactly what you're reading
- right now.
-->
http://fightercore.plesk3.freepgs.com/lala
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /lala was not found on this server.</p>
<address>Apache/2.2.8 (Fedora) Server at fightercore.plesk3.freepgs.com Port 80</address>
</body></html>
[/size]
And there exist other kinds of default data that is transferred when a file is not found, but for now I think my point is clear ^^U.
SeeYaa!
:biggrin:
-
Looks nice. if the file is not found, checking for "<!DOCTYPE" or other HTML tags is not the right thing to do to detect that. It's not invalid if the response code for file not found accompanies an empty document or something that doesn't contain any html markups. It wont be illegal if it returned a picture too..png or otherwise as long as the response code is 404. Isn't there anything in WinINet to get the response code of the last request? Like 202 = success? Cant exactly remember... its been a while since I last worked on http server code.
-
That is compressed or uncompressed ? sounds good if it's uncompressed ^^
That is uncompressed - just straight-forward PNGs. Titles would probably be the same size roughly.
-
This is all looking cool.
We could extend it to all resources - localisation templates, game list localisation files, previews, flyers, pcbs, cheats, history, etc.
-
// Very simple module to download a file using WinInet API (CaptainCPS-X)
#include "burner.h"
#include <wininet.h>
// TODO:
// - Verification of PNG headers instead of checking for regular errors on transfered files
// - Checking of more specific directory to download images form, Ex. flyers/ titles/ cabinets/ etc.
// right now the directory is specified in the server URL.
int FileDownload(TCHAR* szLocalFilePath, TCHAR* szFile)
{
HINTERNET url, open;
int errorCode = 0;
DWORD buffer = 0;
char *content;
FILE* dlPointer = NULL;
TCHAR szFILESERVER1[512] = _T("http://fightercore.plesk3.freepgs.com/files/neosource/fba/support/previews/");
TCHAR szFinalURL[512] = _T("");
// Prepare final URL for current download
_stprintf(szFinalURL, _T("%s%s"), szFILESERVER1, szFile);
// Start initialization for this connection
open = InternetOpen(_T("FBA_Download"), INTERNET_OPEN_TYPE_DIRECT, NULL, NULL, 0);
// Connect to the final URL to start transfer later
url = InternetOpenUrl(open, szFinalURL, NULL, 0, INTERNET_FLAG_NO_AUTO_REDIRECT, 0);
TCHAR szStatusCode[32];
DWORD dwStatusCodeSize = 32;
if (!HttpQueryInfo(url,HTTP_QUERY_STATUS_CODE,szStatusCode, &dwStatusCodeSize, NULL))
{
// server not available so error here
}
else
{
long nStatusCode = _ttol(szStatusCode);
if (nStatusCode == HTTP_STATUS_OK)
{
// Create a new empty file for writing binary data
dlPointer = _tfopen(szLocalFilePath, _T("wb"));
TCHAR szContentSize[32];
DWORD dwContentSizeSize = 32;
if (HttpQueryInfo(url,HTTP_QUERY_CONTENT_LENGTH,szContentSize, &dwContentSizeSize, NULL))
{
long nContentSize = _ttol(szContentSize);
content = (char*)malloc(nContentSize);
// Transfer the file contents and write them to the created file
while(InternetReadFile(url, content, sizeof(content), &buffer) && buffer != 0) {
fwrite(content, 1, buffer, dlPointer);
content[buffer] = '\0';
}
// Done with file writing so close the file pointer
fclose(dlPointer);
errorCode=1;
}
}
else
{
// not code 200 so error here
errorCode= nStatusCode;
}
}
if (content!=NULL)
{
free(content);
}
buffer = 0;
InternetCloseHandle(url);
InternetCloseHandle(open);
return errorCode; // All good!
}
Basic http code checking. Probably not full thought through everything here but it seems to work ok-ish.
-
Cool! ThanX KEV! ^^ Looks good!, I'm gonna check the code asap
SeeYaa!
:biggrin:
-
Here is the other code I have in sel.cpp for the Download feature (still not finished)
FIND THIS >>>>
// Try to load a .PNG preview image
_tcscpy(szBaseName, szPreviewDir);
_tcscat(szBaseName, BurnDrvGetText(DRV_NAME));
if (nIndex == 1) {
_stprintf(szFileName, _T("%s.png"), szBaseName);
fp = _tfopen(szFileName, _T("rb"));
if (fp) break;
}
if (!fp) {
_stprintf(szFileName, _T("%s-p%02i.png"), szBaseName, nIndex);
fp = _tfopen(szFileName, _T("rb"));
if (fp) break;
}
if (!fp && BurnDrvGetText(DRV_PARENT)) { // Try the parent
_tcscpy(szBaseName, szPreviewDir);
_tcscat(szBaseName, BurnDrvGetText(DRV_PARENT));
if (nIndex == 1) {
_stprintf(szFileName, _T("%s.png"), szBaseName);
fp = _tfopen(szFileName, _T("rb"));
if (fp) break;
}
if (!fp) {
_stprintf(szFileName, _T("%s-p%02i.png"), szBaseName, nIndex);
fp = _tfopen(szFileName, _T("rb"));
if (fp) break;
}
}
ADD THIS AFTER >>>>>
// Download image code (preliminary) ------------------------------------------------------
if(!fp){
TCHAR szImageFile[256] = _T("");
_tcscpy(szBaseName, szPreviewDir);
_tcscat(szBaseName, BurnDrvGetText(DRV_NAME));
// Main Image
if (nIndex == 1) {
_stprintf(szFileName, _T("%s.png"), szBaseName);
_stprintf(szImageFile, _T("%s.png"), BurnDrvGetText(DRV_NAME));
if(FileDownload(szFileName, szImageFile))
{
fp = _tfopen(szFileName, _T("rb"));
}
if (fp) break;
}
// Alternate Images
if (!fp) {
_stprintf(szFileName, _T("%s-p%02i.png"), szBaseName, nIndex);
_stprintf(szImageFile, _T("%s-p%02i.png"), BurnDrvGetText(DRV_NAME), nIndex);
if(FileDownload(szFileName, szImageFile))
{
fp = _tfopen(szFileName, _T("rb"));
}
if (fp) break;
}
// Try parent
if (!fp && BurnDrvGetText(DRV_PARENT))
{
_tcscpy(szBaseName, szPreviewDir);
_tcscat(szBaseName, BurnDrvGetText(DRV_PARENT));
if (nIndex == 1) {
_stprintf(szFileName, _T("%s.png"), szBaseName);
_stprintf(szImageFile, _T("%s.png"), BurnDrvGetText(DRV_PARENT));
if(FileDownload(szFileName, szImageFile))
{
fp = _tfopen(szFileName, _T("rb"));
}
if (fp) break;
}
// Alternate Parent Images
if (!fp) {
_stprintf(szFileName, _T("%s-p%02i.png"), szBaseName, nIndex);
_stprintf(szImageFile, _T("%s-p%02i.png"), BurnDrvGetText(DRV_PARENT), nIndex);
if(FileDownload(szFileName, szImageFile))
{
fp = _tfopen(szFileName, _T("rb"));
}
if (fp) break;
}
}
}
// ----------------------------------------------------------------------------------------
As far as i have tested, the last filedl.cpp KEV posted is working good with this updated code, If anyone have issues with it please let me know ^^
SeeYaa!
:biggrin:
-
Oops! there is something I need to implement because if when trying to download a file if the directory doesnt exist FBA will crash xD, so I need to check if the directory exist, if not then create a dir before proceeding to create a new file for download ^^
SeeYaa!
:biggrin:
-
have a look around line 690 in main.cpp, that will show you how to do it., :)
-
have a look around line 690 in main.cpp, that will show you how to do it., :)
ThanX! ^^ I was thinking about something like that
btw, to make it easier to I modded the 'UpdatePreview(TCHAR *szPreviewDir)' function parameters to this 'UpdatePreview(TCHAR *szPreviewDir, int nImageType)' that way we can handle the directories perfectly, it doesnt matter if the user configured a directory from a USB drive, or a network path...here is and example...
Something like this could be done in filedl.cpp
switch(nImageType)
{
case 0: // previews
case 1: // titles
case 2: // flyers
...
}
I think the modification of that function is worth ^^, because that way the file download function will be able to know what directory in the server to look for a image!
SeeYaa!
:biggrin:
-
Hi guys! I think the feature is almost done, lot of stuff has been checked (if not all), you can test my current build to see how the image downloading feature works by now
The current images available at my server are 'previews' and 'titles', I still need the cabinets, flyers, marquees, pcbs and control panels, but I hope to get them and upload them soon ^^ (help is welcome :biggrin:)
I will attach the latest 'filedl.cpp' and other modified files for reference too
EDIT:
I forgot to say you must have this in 'burner_win32.h'...
// filedl.cpp
int FileDownload(TCHAR* szLocalImageDir, TCHAR* szLocalFilePath, TCHAR* szFile, int nImageType);
SeeYaa!
:biggrin:
-
Barry I noticed a bug happening in the official build, when the Game Info dialog is up, and start navigating and clicking around, the gamelist behind it still receiving mouse input and changing variables in memory, like the game that is currently selected...so the Game Info dialog is there but its like if it was transparent to mouse input...
I think this is probably because the way a game is selected is determined by checking the mouse commands and coordinates of the mouse action...so probably this can be fixed by temporally hiding the Game selection dialog while the Game Info dialog is active. Other way this can be probably fixed is by changing the way a game is selected in the gamelist, iirc I have a alternate way in my old Enhanced build, so I'll be checking out my old sources to see if I can help on this matter.
SeeYaa!
:biggrin:
-
small glitch: mapping the game inputs for a game that uses a wheel or a flight stick -> when checking the state of the control and shift keys, one always appears to be in the ON state even when letting go.
-
I took some time to update 'sel.cpp' a bit...I removed a lot of old code for the game selection dialog buttons that I placed long time ago all around 'sel.cpp', everything replaced with like 7 lines of simple code ^^ that do the same job, there are 2 new files that must be added to FBA source for this lines to work...'imagebutton.h', 'imagebutton.cpp' (both can be found attached in this post + the updated 'sel.cpp')
In other news, the issue with the Gamelist and the Game Info dialog is preliminary fixed by making the Game selection dialog to hide while looking at a Game Info :smilie:, modifications for this where little and can be located in 'gameinfo.cpp', 'burner_win32.h' and 'sel.cpp'.
Basically I made the handle of the Game Selection dialog global, made it external so other modules can use it, and placed 'ShowWindow(hSelDlg, SW_HIDE)' and 'ShowWindow(hSelDlg, SW_SHOW)' in the Game Info module ^^.
I hope this updates can be implemented in the official build since it cleans and fix some things :smilie:
PS: Almost done downloading MAME flyers, cabinets, marquees and cpanels (still haven't found a good place to download PCBs package), when finished with download I will get from those only the needed files that FBA will use and upload them to my server.
SeeYaa!
:biggrin:
-
I made a quick update to the Game Selection window too, you can see the attached pictures and compare before and after the update ^^
app.rc and sel.cpp are attached in the previous post with latest updates
Look at the previews locations ;p
SeeYaa!
:biggrin:
-
I took some time to update 'sel.cpp' a bit...I removed a lot of old code for the game selection dialog buttons that I placed long time ago all around 'sel.cpp', everything replaced with like 7 lines of simple code ^^ that do the same job, there are 2 new files that must be added to FBA source for this lines to work...'imagebutton.h', 'imagebutton.cpp' (both can be found attached in this post + the updated 'sel.cpp')
In other news, the issue with the Gamelist and the Game Info dialog is preliminary fixed by making the Game selection dialog to hide while looking at a Game Info :smilie:, modifications for this where little and can be located in 'gameinfo.cpp', 'burner_win32.h' and 'sel.cpp'.
Basically I made the handle of the Game Selection dialog global, made it external so other modules can use it, and placed 'ShowWindow(hSelDlg, SW_HIDE)' and 'ShowWindow(hSelDlg, SW_SHOW)' in the Game Info module ^^.
I hope this updates can be implemented in the official build since it cleans and fix some things :smilie:
PS: Almost done downloading MAME flyers, cabinets, marquees and cpanels (still haven't found a good place to download PCBs package), when finished with download I will get from those only the needed files that FBA will use and upload them to my server.
SeeYaa!
:biggrin:
Thanks for that. I've merged in the changes.
I haven't used the fix for the gameinfo problem though. It breaks the modal property of the dialog meaning that the user can use the menus. It's also not a great fix for when the dialog is called from the menu. Can you describe the problem in more detail and I'll look for an appropriate fix?
Be careful with UpdatePreview() too. I need to centralise it as it's used in various parts of the app slightly different each time - I need to consolidate those into one function. The nImageType function isn't needed either - if you need to know what you're rendering check the szPreviewDir variable. I plan on consolidating this function very soon.
I have also attached an updated imagebutton.cpp file too - I fixed various warnings in it.
-
Thanks for that. I've merged in the changes.
I haven't used the fix for the gameinfo problem though. It breaks the modal property of the dialog meaning that the user can use the menus. It's also not a great fix for when the dialog is called from the menu. Can you describe the problem in more detail and I'll look for an appropriate fix?
Be careful with UpdatePreview() too. I need to centralise it as it's used in various parts of the app slightly different each time - I need to consolidate those into one function. The nImageType function isn't needed either - if you need to know what you're rendering check the szPreviewDir variable. I plan on consolidating this function very soon.
I have also attached an updated imagebutton.cpp file too - I fixed various warnings in it.
I removed my preliminary fix because i didnt notice the modal property being affected, and it didnt solve the problem completelly because sometimes it was still happening T___T
In my point of view nImageType is needed because if the user changes the previews directory name for example to 'c:\mybestpreview\' then 'szPreviewsDir' would not have its default value and the File Download function wouldn't be able to know what dir it should look for in my server...check the following pieces of my current code at filedl.cpp and you should see what I mean...
// This will return directory name without '/' or '\\'
TCHAR* getImageDirectory(int nImageType)
{
TCHAR szDirs[DIRS_MAX][MAX_PATH] = {
{_T("previews")}, // 0
{_T("titles")}, // 1
{_T("flyers")}, // 2
{_T("cabinets")}, // 3
{_T("marquees")}, // 4
{_T("controls")}, // 5
{_T("pcbs")}, // 6
};
return szDirs[nImageType];
}
TCHAR szFILESERVER1[512] = _T("http://fightercore.plesk3.freepgs.com/files/neosource/fba/support/");
TCHAR szFinalURL[512] = _T("");
// Prepare final URL for current download
_stprintf(szFinalURL, _T("%s%s/%s"), szFILESERVER1, getImageDirectory(nImageType), szFile);
And if I remove all that code and simply use the value inside 'szPreviewsDir' variable, the instead of looking for 'http://myserver.com/previews/' in the server URL would be looking for 'http://myserver.com/c:\mybestpreview\' ...this would be happening with Flyers, Cabinets, CPanels, etc too.
Right now I know what you mention about being careful with UpdatePreview(), because there are 2 of the functions located in 'sel.cpp' and 'gameinfo.cpp', both are a bit different in some ways of each others, including one having less parameters.
Oh and I will post some pictures of the problem with the Game Selection dialog and the Game Info asap :wink:
SeeYaa!
:biggrin:
-
You need nImageType there - but not in UpdatePreview(). :)
-
Here i bring 2 pictures of the problem, if i change tabs the problem will still be there and probably will look for other game images while i change tabs, the other information like rom info will not change, its only a problem with images...very strange
SeeYaa!
:biggrin:
-
You need nImageType there - but not in UpdatePreview(). :)
Here is how Im using it right now (btw Im not telling you're wrong I just explaining my reasons, and trying to figure out another way based on your points ^^)...
this is in gameinfo.cpp...
if (Msg == WM_NOTIFY) {
NMHDR* pNmHdr = (NMHDR*)lParam;
if (pNmHdr->code == TCN_SELCHANGE) {
int TabPage= SendMessage(hTabControl, TCM_GETCURSEL, 0, 0);
if (TabPage == 0) UpdatePreview(szAppPreviewsPath, 0);
if (TabPage == 1) UpdatePreview(szAppTitlesPath, 1);
if (TabPage == 2) UpdatePreview(szAppFlyersPath, 2);
if (TabPage == 3) UpdatePreview(szAppCabinetsPath, 3);
if (TabPage == 4) UpdatePreview(szAppMarqueesPath, 4);
if (TabPage == 5) UpdatePreview(szAppControlsPath, 5);
if (TabPage == 6) UpdatePreview(szAppPCBsPath, 6);
if (TabPage == 7) DisplayRomInfo();
if (TabPage == 8) DisplayHistory();
return FALSE;
}
}
BUT I think your point is I should handle nImageType like a global integer and not like a parameter depending the situation, right? ^^
Well i will start removing the parameter to try with a global int :smilie:
SeeYaa!
:biggrin:
-
Hmmm, I can't recreate the gameinfo problem at all. Can anybody else? What OS are you using?
For UpdatePreview() - if you want to find out what type of image is being requested then just use szPreviewPath as I said. See this example from the gameinfo.cpp UpdatePreview() function.
if (fp) {
int Screenshot = 0;
if (szPreviewDir == szAppPreviewsPath || szPreviewDir == szAppTitlesPath) Screenshot = 1;
hNewImage = LoadPNG(hGameInfoDlg, fp, Screenshot);
fclose(fp);
}
This checks the path to see if it is a preview or title and if it is then it tells the LoadPNG function that it is loading a screenshot and then it gets the aspect ratio from the driver to display the image - otherwise it uses the original image aspect ratio. This is an example of how to recognise the image type from the path.
-
ThanX for taking a time to look at the issue Barry ^^, here you have some info of my system...
----------------------------------------------------------------------
System information:
OS: Microsoft Windows XP Professional Service Pack 3 (build 2600)
CPU: GenuineIntel, P6 family
1833 MHz, MMX, SSE, SSE2 (2 system processors)
Physical RAM: 1046572 KB (1022 MB) total, 408936 KB ( 399 MB) avail
Total RAM: 4194303 KB (4095 MB) total, 4194303 KB (4095 MB) avail
FB Alpha: 11612 KB in use (13016 KB peak, 12336 KB virtual)
Installed displays and display adapters:
Plug and Play Monitor on NVIDIA GeForce Go 7400 (primary)
Plug and Play Monitor on NVIDIA GeForce Go 7400 (disabled)
and about the UpdatePreview() I removed all the parameter modifications and made 'int nImageType' a global variable.
now the only thing I did to handle its value is this ^^ at gameinfo.cpp
if (Msg == WM_NOTIFY) {
NMHDR* pNmHdr = (NMHDR*)lParam;
if (pNmHdr->code == TCN_SELCHANGE) {
int TabPage = SendMessage(hTabControl, TCM_GETCURSEL, 0, 0);
nImageType = TabPage;
if (TabPage == 0) UpdatePreview(szAppPreviewsPath);
if (TabPage == 1) UpdatePreview(szAppTitlesPath);
if (TabPage == 2) UpdatePreview(szAppFlyersPath);
if (TabPage == 3) UpdatePreview(szAppCabinetsPath);
if (TabPage == 4) UpdatePreview(szAppMarqueesPath);
if (TabPage == 5) UpdatePreview(szAppControlsPath);
if (TabPage == 6) UpdatePreview(szAppPCBsPath);
if (TabPage == 7) DisplayRomInfo();
if (TabPage == 8) DisplayHistory();
return FALSE;
}
}
Back to the image issue and the game selection, I noticed something interesting about the problem, the popup menu seems to have something to do with this...check the attached picture to see what I mean...oh and this is happening is you first select a game , for example '1000 Miglia: Great 1000 Miles Rally (94/07/18)' and after having it selected, select (using right click only and without left clicking it first) '19XX - the war against destiny (951207 USA)'...the menu will come and when you go to the Game Info dialog go to Titles tab, you will see the problem there...so I think the problem has to do with the Right Click and PopUp menu event.
The problem will not happen is you select a game with Left Click first and then Right Clicking on it again to see its game info.
those are my findings so far
SeeYaa!
:biggrin:
-
Hmmm, I can't recreate the gameinfo problem at all. Can anybody else? What OS are you using?
I can recreate it under XP HOME. Go to a game's game information window and switch around with 'Title' and 'In Game' tabs. For me, it changes from the start at the most twice and then it stops. On top of that once you start moving the window vertically and switch 'Title' and 'In Game' again, it will select even more games. Most of the time it looks as if it's being very specific as to what image it'll bring up, based on where the top of your window is sitting, but a few times it will just randomly pick the game that's just underneath visibility of scrolling to.
System Information
------------------
Time of this report: 8/10/2008, 21:15:00
Operating System: Windows XP Home Edition (5.1, Build 2600) Service Pack 2 (2600.xpsp_sp2_gdr.070227-2254)
Language: English (Regional Setting: English)
System Manufacturer: Gateway
System Model: E-4000
BIOS: BIOS Date: 10/16/02 08:39:45 Ver: 08.00.05
Processor: Intel(R) Pentium(R) 4 CPU 2.40GHz
Memory: 1022MB RAM
Page File: 324MB used, 1628MB available
Windows Dir: C:\WINNT
DirectX Version: DirectX 9.0c (4.09.0000.0904)
DX Setup Parameters: Not found
DxDiag Version: 5.03.2600.2180 32bit Unicode
-
Not sure if I'm posting what CPS-X has already figured out but I can now see definite order in the problem. Check my PNG's
(couldn't post attachments were too large, sorry!)
(Edited by CaptainCPS-X: Attached the files for you ;p, ThanX for the research)
-
After lot of try and fail I came up with an idea that fixed without any issues the problem of the previews, since the GameInfo module only will handle 1 specific game info at a time, I modified the "GameInfoDialogCreate()" with 3 new parameters "BurnDrvGetText(DRV_NAME), BurnDrvGetText(DRV_PARENT), BurnDrvGetText(DRV_BOARDROM)" and when those values are handled in GameInfo module are passed to global variables located statically in there, that way there is no way that previews or images from another game are displayed.
BUT this way is wrong because UpdatePreview() must be consolidated and this fix complicate that matter as well. So its a dirty fix for now.
Im trying to consolidate the function but what makes it difficult is the Timer feature in sel.cpp not used in gameinfo.cpp...Im thinking on adding the Timer for alternate images (Ex. 19xx-p01.png) in gameinfo.cpp as well to make it easier to consolidate the UpdatePreview() function.
SeeYaa!
:biggrin:
-
It's a weird one. I've fixed it in a similar way but I've also got the aspect ratio at init time as well so that we don't get incorrectly stretched images.
It wasn't UpdatePreview() I was meaning to consolidate. Mistake on my part - it was all the calls to LoadPNG(). I'm looking into it now - not sure if it's feasible or not.
I still don't think you need nImageType! I would use something like this;
if (szPreviewDir == szAppPreviewsPath) {
// Download preview from server
}
if (szPreviewDir == szAppTitlesPath) {
// Download title from server
}
if (szPreviewDir == szAppFlyersPath) {
// Download flyer from server
}
......
-
It's a weird one. I've fixed it in a similar way but I've also got the aspect ratio at init time as well so that we don't get incorrectly stretched images.
It wasn't UpdatePreview() I was meaning to consolidate. Mistake on my part - it was all the calls to LoadPNG(). I'm looking into it now - not sure if it's feasible or not.
I still don't think you need nImageType! I would use something like this;
if (szPreviewDir == szAppPreviewsPath) {
// Download preview from server
}
if (szPreviewDir == szAppTitlesPath) {
// Download title from server
}
if (szPreviewDir == szAppFlyersPath) {
// Download flyer from server
}
......
Wow I spent a large time and consolidated UpdatePreview() , LoadPNG() and its sub functions xD...it still need a bit of cleaning but those functions are 1 each, they dont repeat over multiple source files. I only need to update the LoadPNG() so it can use diferent sizes because for now all loaded PNGs are the size of the small preview. Apart from that everything is working fine so far.
Im laughing at myself because I didnt understood until now what you was explaining all this time about not needing 'nImageType' xD... I just need to compare variables into UpdatePreview() to know what of the currently configured directories (doesnt matter where are they) matches the one being passed as a parameter at that moment...that of course must be one of the configured directories ... LOL ... man I was in a mind trip xD
Im gonna sleep now but when i come back I will finish the consolidation of all those functions ^^, I hope you can use my final work :smilie:
Take Care!
SeeYaa!
:biggrin: