downloading game levels/files

Was thinking the same but didn't wanna burst a bubble :). dan3008, share the code you don't understand and maybe someone can explain. Where did you get the source from?



Edited 1 time(s). Last edit at 04/19/2010 11:44AM by Kajos.

Quote
yellowstar

Quote
LordAshes
If you were using binary files, such a (compiled c-code) executable or picture files, the files would need to be encoded on the server so that they can be sent in a regular HTTP GET request. This means that the client (the Wii program) would then need a corresponding decoder to convert the files back to their binary format.

No, you can retrieve binary files with HTTP. Just receive the headers, and when you reach a line/"header" with only "\r\n"(line length less than 3) you reached the end of the headers. Then write the received data that follows the empty line to your file buffer. Here's my HTTP implementation: [code.google.com] This library doesn't work on Wii due to strange unknown networking errors, but it can still be used for reference, etc.(This library works on Linux, Win32, and NDS.)

I don't see you calling "net_init()" anywhere, so that might be the problem.

Quote
yellowstar
No, you can retrieve binary files with HTTP. Just receive the headers, and when you reach a line/"header" with only "\r\n"(line length less than 3) you reached the end of the headers. Then write the received data that follows the empty line to your file buffer. Here's my HTTP implementation: [code.google.com] This library doesn't work on Wii due to strange unknown networking errors, but it can still be used for reference, etc.(This library works on Linux, Win32, and NDS.)

I didn't say you could not get binary files via HTTP...of course you can otherwise you would not be able to download all those picture and/or software. What I was saying is that if your webpage is pure text (such as HTML code, a text files, etc) then the response from the server is also in plain text. So you read the response (into, for example, a buffer) and you already have the desired file. However, if the download is binary such as a picture or executable file then it is encoded on the server. Part of the response header indicates the encoding type and the end user must then use that information to decode the downloaded buffer back to the binary file.

This is why, when you install a Web Browser, it offers various plugins for decoding web material. If you don't have the plugin (i.e. the decoder) the encoded data can be downloaded but the Web Browser does not have the instructions on how to re-construct the original file.

Quote
LordAshes
I didn't say you could not get binary files via HTTP...of course you can otherwise you would not be able to download all those picture and/or software. What I was saying is that if your webpage is pure text (such as HTML code, a text files, etc) then the response from the server is also in plain text. So you read the response (into, for example, a buffer) and you already have the desired file. However, if the download is binary such as a picture or executable file then it is encoded on the server. Part of the response header indicates the encoding type and the end user must then use that information to decode the downloaded buffer back to the binary file.

This is why, when you install a Web Browser, it offers various plugins for decoding web material. If you don't have the plugin (i.e. the decoder) the encoded data can be downloaded but the Web Browser does not have the instructions on how to re-construct the original file.

Whow, my bullshit meter just hit red. Everything you just said is wrong.

First, text can be encoded in different character sets, which you might need to handle.
Second, a webserver does not really modify the binary files it sends.
Third, text files have a big chance to be send compressed (bzip2 or zlib compression)
Next, webserver can send chunked encoding, which almost all examples I've seen so far don't handle (especially dynamic content and large files are send chunked)
Also, Webbrowsers have 'decoders' for files yes, but they are no different from decoding the file from disk. If you can read a PNG from disk you can also read one send by a webserver.
Last, only thing extra a webserver does is sending a mimetype with the file. Which identifies the type of file ("image/png" for PNG images for example) and browsers can use that to identify how to handle the file.

ok, wait a moment. First things first. I'm a fairly inexsperienced coder, i dont realy know all that much so i have afew quesions:
1) whats a bin file? and how do you use one?
2) can a bin file contain raw C/C++?
3) how do you get a app to use/run a bin file

1) bin stands for binary. A binary file is any file that isn't text. To know if it is text think of it this way. Try opening a file in notepad. If you can read it then it is text. If it is a bunch of jumbled characters then it is a binary file. A .bin Is a type of executable files, just like a .dol or an .elf

2) raw C / C++ code is text, because you could easily read it through notepad. Not that it makes a difference, because text and binary files are handled the same. If you are talking about the executable formate .bin the answer is no. The C/C++ code needs to be compiled first, the wii cannot just read uncompiled code. If you really want to do this then look up lua for wii. This will let you run uncompilled code, although it is in the language lua.

3) Remember, a binary file is like a .jpg, .png, .mp3, .doc, etc. If you want to read the contents you will have to have a library to decode the format. There are plenty out there for the wii, so this shouldn't be a problem. If you want to run the executable .bin it gets a little more tricky. I believe (an could be wrong) that the better bet is to use a .dol or .elf as the will already has code to execute these file formats.

If any of this doesn't make sense just ask.

ok, i think i get you. so to have levels stored as .bin files and then to run them they would need to be executable format correct? or would i just need to compile the C/C++ into a normal .bin? what libary is needed to decode a .bin file?

otherwise for the better bet (as you put it) how do you execute a .dol from the SD from within an app because i cant make heads or tales of the code myself. I also need to know how to list the .dol's avalable so the user can select the one to be run.

I think you are taking in the wrong direction. Creating and executing another .dol to play a level is a bad idea, it is just extra work. I would create some system where you store the levels in a struct and then have a function that reads the struct and plays the level. That way when downloading levels you only need a few bytes for a level that hundres of kilobytes per level.
NOTE: a .bin is also called a flat binary.don't quote me on this, but It hink all yopu have to do is copy it to memory and then start execution there, but I would heavily suggest the method above.

Quote
Daid
I don't see you calling "net_init()" anywhere, so that might be the problem.

No, yellhttp.c is the source for the library, if_config is called by yellhttptest. That bug was fixed though, IOS rejects IPPROTO_TCP, IPPROTO_IP must be used.

dan3008:
Here's some sample C code for loading a simple level from SD. You can adjust it use a buffer from RAM if needed. This reads a binary file. This is for a tiled level, where only one object can be on each tile.
[pastie.org] (pastie is used since the code doesn't display correct here on forums.)

Quote
g_man
NOTE: a .bin is also called a flat binary.don't quote me on this, but It hink all yopu have to do is copy it to memory and then start execution there, but I would heavily suggest the method above.

No, it's not that simple. You'd need to compile it with -fPIC IIRC, as well as other things to compile a dynamically loaded executable. It's much better to use a simple level file instead of an executable level.



Edited 1 time(s). Last edit at 04/21/2010 03:39AM by yellowstar.

Quote
yellowstar

Quote
g_man
NOTE: a .bin is also called a flat binary.don't quote me on this, but It hink all yopu have to do is copy it to memory and then start execution there, but I would heavily suggest the method above.

No, it's not that simple. You'd need to compile it with -fPIC IIRC, as well as other things to compile a dynamically loaded executable. It's much better to use a simple level file instead of an executable level.

I was try to get him to stray away from using .bin, because it would be overly complicated and not worth the limited benifits of using a .bin. But I was trying to say that if there isn't a call to run .elf or .dol then it might be easier to run a flat binary. But again I was trying to interate that loading an external executable file was a bad idea.



Edited 1 time(s). Last edit at 04/21/2010 06:06AM by g_man.

Quote
yellowstar
dan3008:
Here's some sample C code for loading a simple level from SD. You can adjust it use a buffer from RAM if needed. This reads a binary file. This is for a tiled level, where only one object can be on each tile.
[pastie.org] (pastie is used since the code doesn't display correct here on forums.)

Thankyou yellow star. I'm going to need to sit down and have a good look thorugh your code to get it all straight in my head but that looks like it will fit my needs perfectally.

Can you just brifly exsplain to me how it works to get me started.

also how to make a binary file for use with this code, and what size are the tiles? or is that custom set?

looks good, i just need a coupple of exsplations.
firstly, what format should the .bin take? so would it look like 52 21 5 11 11 6 41 20 ect (where 52 is level hight, 21 is level width, 5 and 6 are object types, 11 and 41 are object x vales and 11 and 20 are object y values.) or should it be diffrent?
secondly, what is newobj->x and y? because i cant see them diclaired anywhere.
thirdly, are level width, hight and object X and Y pixels or grid referance (and if grid refrence what size are the squairs on the grid or is it just made to fill the screen?)
four - what libaries are needed to open/read the .bin files?
Finaly how can i generate an onscreen list of all the .bin files to populate the filename



Edited 2 time(s). Last edit at 04/21/2010 04:01PM by dan3008.

Quote
dan3008
looks good, i just need a coupple of exsplations.
firstly, what format should the .bin take? so would it look like 52 21 5 11 11 6 41 20 ect (where 52 is level hight, 21 is level width, 5 and 6 are object types, 11 and 41 are object x vales and 11 and 20 are object y values.) or should it be diffrent?
secondly, what is newobj->x and y? because i cant see them diclaired anywhere.
thirdly, are level width, hight and object X and Y pixels or grid referance (and if grid refrence what size are the squairs on the grid or is it just made to fill the screen?)
four - what libaries are needed to open/read the .bin files?
Finaly how can i generate an onscreen list of all the .bin files to populate the filename

Offset 0x0 in the level is the levelwidth, offset 0x4 is the levelheight. 52 would be the level width, and 21 the level height in tiles. Followed by levelwidth*levelheight entries of sLevelObject. Yes, 5 and 6 for obj types, and 11/41 and 11/20 for objects' x/y are correct. newobj is a struct for the object type struct. You could add code to the LoadLevel function to dynamically allocate a buffer for the level, and copy the object structs into that. newobj would be a struct ptr to your unique object struct, if the object type has a unique struct. You only need libfat, fat.h, and stdio.h to use SD. x and y are the tile grid coordinates. x for the first tile in the row would be zero, for the next tile would be one, and so on. Devkitpro has an libfat directory listing example: devkitpro/examples/wii/filesystem/directory

Thankyou sooooooooooooooooooo much. will take a look at the example and use that. :):):) two quick questions then i'm done, where do i need to stick the file name inorder to load the correct bin? secondly how big is a tile?

If you'd use directory listing code based on the dirent directory listing example, you'd use something like this: LoadLevel(pent->d_name); The size of the tiles in pixels is not defined, it's whatever size you want.

Quote
yellowstar
If you'd use directory listing code based on the dirent directory listing example, you'd use something like this: LoadLevel(pent->d_name); The size of the tiles in pixels is not defined, it's whatever size you want.

ah, i get it. well that rather simple. :) so is it the level x and level y values that dertermin the size of a tile? and then the object x and y dertermin which tiel it goes on :) coolio. just one thing i forgot, should the bin file be seperated with spaces/commers or do i need to fill the rest of the bites used for each value with 0's? thanks a million

also are you cartain that stdio.h is needed? because i was looking it up and found that Stdio is used for input and output to the "console" but i dont think that needed for this. i could be wrong and have overlooked something. please let me know??



Edited 1 time(s). Last edit at 04/22/2010 09:29AM by dan3008.

Quote
dan3008
ah, i get it. well that rather simple. :) so is it the level x and level y values that dertermin the size of a tile? and then the object x and y dertermin which tiel it goes on :) coolio.

levelwidth is the number of tiles in a row for the level, levelheight is the number of tiles in a column for the level. Yeah the obj x/y determine which tile it is located at.

Quote
dan3008
just one thing i forgot, should the bin file be seperated with spaces/commers or do i need to fill the rest of the bites used for each value with 0's? thanks a million

It's binary, not text. If you want to write levels to SD, you could copy the LoadLevel function and name the copy WriteLevel or so, and change the fread calls to fwrite. Then adjust it so it writes a level passed as a parameter.

Quote
dan3008
also are you cartain that stdio.h is needed? because i was looking it up and found that Stdio is used for input and output to the "console" but i dont think that needed for this. i could be wrong and have overlooked something. please let me know??

stdio.h is needed for reading/writing files with SD. It has the fopen, fread, close function prototypes, as well as the FILE struct definition.

ok, thats not a problem, thanks. you have been an excelent help.

I just dont get one thing, how does it know where the diffrent values start and end if they can be variable lengh and have no seperator??

Quote
dan3008
I just dont get one thing, how does it know where the diffrent values start and end if they can be variable lengh and have no seperator??

That code assumes all the tiles are the same size, defined by the size of sLevelObject. This means every time you change the sLevelObject struct you must rewrite/export your levels. Remember this is binary. You can create your levels by either exporting them from your app, or with a hex editor. Not any text editor, this is binary.

I can exsport levels directally from my app????? wow, that would be realy usefull. how do i do that? and how do i set the sLevelObject variables? will they be from the bin file or do i need to manualy set them?

Quote
dan3008
how do i do that? and how do i set the sLevelObject variables? will they be from the bin file or do i need to manualy set them?

You'd manually set them. You can export levels with this.