Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / OpentoRead Only Read First Value

Author
Message
TheViking
12
Years of Service
User Offline
Joined: 16th Feb 2012
Location:
Posted: 11th Jul 2014 06:04
Hey,

Just curious, is there anything wrong with this bit of code? I have a tile editor program I made, and on there I can load a text file filled with integers and save into an array with no issues. Now, when I tried an identical code for a new program and tried opening that same text file to fill an array, it will only see the first value. The second value shows as zero.

This is the simplified code I use to just pick a few numbers from the text to test it.



Nothing special. The text file is simply just numbers separated by spaces. As I said, the first number (SpriteID) shows correctly, but the rest return 0. Anything that stands out? Thanks
JimHawkins
14
Years of Service
User Offline
Joined: 26th Jul 2009
Location: Hull - UK
Posted: 11th Jul 2014 08:16
The help file says that ReadString() returns a NULL terminated string. Looks to me like your first call returns the entire content and then can't read any more.

Change the spaces to CR/LF use ReadLine() instead.

-- Jim - When is there going to be a release?
Jack
19
Years of Service
User Offline
Joined: 4th Oct 2004
Location: [Germany]
Posted: 11th Jul 2014 09:43 Edited at: 11th Jul 2014 09:43
You could try to replace the ReadString() with ReadLine() this could work In your code

http://www.appgamekit.com/documentation/Reference/File/ReadLine.htm

[/url]
Naphier
13
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 11th Jul 2014 10:32
If it is just numbers separated by some token (in your case spaces - I often use commas) then do one ReadLine and parse the data with GetStringToken(line$ , " " , iPosition)
Not sure how you got this to work in your original code as it is expecting a text file like this:
1[NULL]2[NULL]3[NULL]4[NULL]
Null is very different from spaces.
How are you saving the data to the file?

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 11th Jul 2014 12:59
One issue might be that if the whole file was less than 256 bytes, and now it isn't. Like if you had some test data in the file, the readstring would read the whole lot and not run into any problems because it might just be 1 line. Then, you populate the file with real data that exceeds 256 bytes, and readstring struggles with that.

So, as others have already said, use readline because readstring loads your whole file as a single, massive string, and that's typically not the best way to work. A sensible limit for strings is 256 bytes, some systems even enforce this limit.

I am the one who knocks...
TheViking
12
Years of Service
User Offline
Joined: 16th Feb 2012
Location:
Posted: 11th Jul 2014 23:33
Thanks, I forgot about the readline. However, it would be nice to have it where each line would contain the .spriteid and .properties before the return, since this would be quite a long file having to have each thing on a new line, but it works. Thanks again.
Naphier
13
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 12th Jul 2014 01:11
I do my data like this (fictitious example):
data$ = str(spriteID) + "," + str(w#,4) + "," + str(h#,4)
WriteLine(fileID , data$)
Then get it back in with
line$ = ReadLine(fileID)
spriteID = val(GetStringToken(line$ , "," , 1))
spriteID = valFloat(GetStringToken(line$ , "," , 2))
spriteID = valFloat(GetStringToken(line$ , "," , 3))

and so on.
The data is pretty compact this way.
Another alternative is using memblocks where you can make it even more compact, but it gets a bit more annoying to parse.

Marl
12
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 12th Jul 2014 18:59
I use the same method to Naphier, but sometimes use "parm=val," format to allow the presence and order of the parameters to change;
"X=100,Y=200,W=64,H=64,R=255,G=128,B=0"
The same process applies to get the pairs.
TheViking
12
Years of Service
User Offline
Joined: 16th Feb 2012
Location:
Posted: 17th Jul 2014 06:38
Thanks guys, that helped a lot. Sorry for the late response. Moving and such takes time out. Just one further question if anyone is still reading this post. It appears that some sprites have a black line showing here and there as though it's taking part of the sprite above or beside, though these lines can be faded. Here's what I have for code. I checked all of the sprites and they are within the 32x32 sizes on the sheet.

For the Sprite Loading:


And for globals needed:


Is there something that stands out? Thanks again.
Naphier
13
Years of Service
User Offline
Joined: 2nd Oct 2010
Location: St Petersburg, Florida
Posted: 17th Jul 2014 10:17
You have 1024 frames of 32x32? How big is your sprite sheet (too late to math)?
DirectX on Windows can probably handle a sheet up to 4096x4096, but if you're going to release on mobile then you'll want to limit it to 1024x1024 (2048x2048 if you're not developing for iOS - AGK's OpenGL on iOS can't do bigger than 1024x1024 textures).

You might be pushing the limits of the graphics API. Also I've noticed it often has issues with pixels within 2 pixels of the frame edge. It seems to happen on Windows more than mobile. Probably something to do with the scaling of the window in addition to the scaling of the texture. Sometimes this happens on mobile too. With my tile sheets I make sure that I have extra pixels "overdrawing" the image. With most of my animation sheets I ensure there's at least 2 pixels on each side of each image (so 2 pixels around the border of the atlas and then 4 pixel between each sprite). This seems to do the trick.
If you're using AGK's generated mipmaps (SetGenerateMipmaps(1))that also might be a cause of the issue. But I would suggest tweaking the images with more padding before getting rid of mipmapping.

Marl
12
Years of Service
User Offline
Joined: 19th Nov 2011
Location: Bradford, UK
Posted: 17th Jul 2014 14:35 Edited at: 17th Jul 2014 14:40
Quote: "You have 1024 frames of 32x32? How big is your sprite sheet"

Assuming its square, It'd be 1024x1024 pixels (32 cells x 32 cells, each 32x32 pixels).
Quote: "It appears that some sprites have a black line showing here and there as though it's taking part of the sprite above or beside, "

That is exactly what is happening. The adjacent frame is bleeding in due to anti aliasing.
You can either incorporate a blank border around each frame as Naphier suggests (quite costly in a 32x32 tile) or use the commands;
- SetImageMagFilter( iImageIndex, mode )
- SetImageMinFilter( iImageIndex, mode )
to set how mapping occurs.
TheViking
12
Years of Service
User Offline
Joined: 16th Feb 2012
Location:
Posted: 18th Jul 2014 03:04
Thanks! That seemed to do it... just a few issues with the way it looks, ie: cuts out a few black outlines, but it's tolerable. The mag and min filters did it.

Login to post a reply

Server time is: 2024-04-25 06:47:39
Your offset time is: 2024-04-25 06:47:39