ID:151673
 
My game runs perfectly until I use a JPG file that's 72kb. It runs perfectly until I call my shoot proc. Before I used this JPG file however, the shoot procedure worked fine without lag.

What's going on? My shoot proc has no infinite loops and only consists of 1-2 loops checking basic things.
The JPG needs to be compressed. If the highest possible quality is used it will cause the game to be slow because it has to load it before hand, and (Depending on what the jpeg is being used for) load it all the time in certain situations.
Showing the proc would be nice.

So we could see how the JPEG file is being used.
In response to UmbrousSoul
The JPG is being used as part of the map. Like the streets and whatnot. There's no procedure related to these JPEGS.
In response to Speedro
Its related to the quality of the jpeg itself, I never said any programming was involved.

You simply need to lower the quality, I can do it for you if you want.

Espeically if its being incorporated actively into the map, that is what I was hinting on.
In response to UmbrousSoul
So would it be more appropriate to just not worry about JPGS and just icon everything individually?
In response to Speedro
You shouldn't be using a .jpg anyway. It's a rubbish file format for this sort of purpose. You should be using a .png (which is essentially what the .dmi format uses now).

And I really, really, really doubt that just having a large .jpg is "causing lag". Showing some code would help in, you know, telling you what went wrong.
In response to Garthor
I'm just going off the fact that with the interface if you have a high quality png/gif skin takes longer to load. I use jpg for my images because it allows custom file sizes to be set, and allows more quality control for the interface.

So I imagine if a jpg is used on the map as a constant it Would lag.
In response to UmbrousSoul
JPGs are god awful, your just torturing your players for using them.
PNG's are as big (filesize) as DMI's, so unless you don't wanna use DMI's, it's silly to avoid PNGs.
In response to UmbrousSoul
A .jpg is a file format specifically for use in photos (or anything "realistic"). When used for anything besides that (say, an interface), the files are heavily artifacted and larger than a .png.

Regardless, your conclusion is completely false, though I have trouble saying exactly why because I'm simply unable to parse it. I have no idea what you mean by "if a jpg is used on the map as a constant". I can say that using a larger file will result in a larger initial download of the resources, but again this isn't "causing lag".
In response to Garthor
Well there is no programming to look at so what do you think it is genius?

I just switched all the jpgs I was using into PNG24 and the point I was making is that the png (in PS7) has no quality control like jpg, making it take longer to load.

I would say the jpg I had at about 60-80% quality (while still looking perfectly fine - I am using a 720p monitor) loaded faster then the PNG24's by atleast 3 or 4 seconds.

And what I mean by constant is something that is always overlaying the display area.

Bet you think its fun to just delete the responses so you still seem like king but you know what you guys are so it needs no repeating.
In response to UmbrousSoul
UmbrousSoul wrote:
Well there is no programming to look at so what do you think it is genius?

Programming. And, while I am technically a genius, I prefer not to be referred to as such, as I find it rather snobby.

I just switched all the jpgs I was using into PNG24 and the point I was making is that the png (in PS7) has no quality control like jpg, making it take longer to load.

I would say the jpg I had at about 60-80% quality (while still looking perfectly fine - I am using a 720p monitor) loaded faster then the PNG24's by atleast 3 or 4 seconds.

If you take a .jpg and turn it into a .png, the file is going to be larger because the .png now has to save all the .jpg artifacts (as opposed to a clean image). You need to save from a high-quality, uncompressed source image.

And what I mean by constant is something that is always overlaying the display area.

This has nothing to do with anything whatsoever. The image isn't being re-downloaded every frame.
In response to UmbrousSoul
I know this is just too simple to be considered and would likely strip you and Garthor of the opportunity to have such a nice 'hidden insult'-debate, but for the sake of actually solving the trouble you're experiencing, would you consider creating a sample project?
This should be a complete new project with just the jpg/png file on the map and a visual representation for the player.

If this still lags, you can offer it to Garthor for download and he can check it out, then hand constructive feedback.
If it does not lag, you can be sure that there is another issue. This might very well be a synergistic effect, but it would still be a valid first step to eliminate the most basic possibilities, for the sake of easy debugging.
In response to UmbrousSoul
Garthor is entirely correct. The .png format is superior to .jpg in every way but one: JPEG is good for compressing photos. In anything with a high information density, lossy compression often yields nice results without noticeable artifacts. For anything meant to be used as an item on the map, though, artifacts would be quite obvious and preserving detail is crucial. I can see using a JPEG image for a skin background or something like a title screen, but not for game icons.

But really this whole discussion is a sidetrack off the original poster's problem, which is that he's having some kind of issue in his game based on how he's using the JPEG file. Without more info there's no way to tell what's happening at his end.

Lummox JR
In response to Lummox JR
I simply resorted to changing the png file in to hundreds of 32x32 dmi files, which stopped all the lag.
In response to Speedro
That is what happens when you place a large .png on the map anyway.
In response to Garthor
Stopped the lag though. :s No difference in coding.
In response to Speedro
Oh, a possibility I had thought of earlier but never mentioned: were you doing any icon operations? If you are performing 100 icon operations on a 320x320 image, it will be much slower than 100 icon operations on 100 32x32 images.
In response to Garthor
Absolutely none; except the turf calling Enter when a bullet comes in contact with it- which isn't crazily often...
In response to Speedro
It wouldn't have to happen often because even doing one operation on a very large .png would produce a noticeable slowdown.
Page: 1 2