1. Compress your resources (loosely) into a ZIP archive2. Apply a simple encryption algorithm (really simple, since the purpose here isn't to 'keep them out' so much as it is to making it not so blunt to acquire access to the resources. Also, the encryption algorithm is entirely local so there isn't much in the way of someone tearing apart your usage of the Java encryption API and grabbing the key if they really wanted it anyway...) So (in this example) XOR encryption.3. Decorate a FileInputStream (to the Zip Archive containing your resources) with an XorDecryptionInputStream (basically just applies an XOR to every byte you read from the stream to decrypt it. A simple one byte key is entirely sufficient for these purposes) and pass that to the ZipInputStream5. Use the ZipInputStream as you would.

Thanks mate ^_^

I made a program that:Takes the resource (.png) than imports the raw .png data for encryption prior to exporting it into the cache.dat file ^_^

Next thing I need to think about is how to retrieve a certain object in the .dat cache file, should I use resource headers?(The headers will be encrypted also ^_^)

Here is the cache.dat file contents (pseudo):

Quote

<!-- ShopIcon.png --!>ENCRYPTED DATA HERE

<!-- AttackIcon.png --!>ENCRYPTED DATA HERE

Note:Since I can't post the encrypted data on the text area on JGO and successfully click post, here are the links ^_^I'm happy with the output, there's no tenfold on the encryption files size.

I mainly don't want my resources 'bluntly' out in the open Now I know I can't fully stop people from grabbing/editing the resources but I'd like to remove the 'bluntly' part and possibly store everything in "Cache files" ^_^ (.dat etc)

You aren't going to get smooth gameplay if you are literally just sending player coordinates.

Thanks ^_^, I'm not familiar with interpolation / client side prediction yet.Is that what you mean by your quote above?

Below is 2 code snippets, would both of them have the same effect on sending/receiving players positions?Meaning: would both snippets below send the data in the same amount of time, and not cause the players position to be updated slightly later due to snippet #2's length?

Last night was the first time I ever implemented rendering via a BufferStrategy and let me say I'll never regular render lol.

I was rendering a 1024x600 (Image file: 1920, 1200) via simply overriding the JPanels paint method and I was only pulling around 20 FPS :/

I couldn't stand having a low FPS so I Googled for performance tuning 2D and I found 5-7 useful hints on 1 page and some of them were:Use a BufferStrategy (Via a canvas)Use GraphicsDevice.createCompatibleImage()etc..

Anyhow, I switched to rendering the chunky Image on a double buffered BufferStrategy and the rest via Graphics2D (Super RenderingHints) and my FPS is now around 60-90.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org