wagic.the.homebrew e27cf56fa2
- Support for Zip Filesystem. It is now possible to zip the entire Res folder ("store" method preferred, zip so that the root of the zip has ai, player, etc...) in one single file for read only. Write access is done in another folder (hardcoded to be User/ for now, can be updated depending on platforms, etc... ...
-- zipFS has several limitations...
--- in a general way, seekg doesn't work... so getting a file's size needs to be done through JFileSystem.
--- getLine on files open with zipFS doesn't work so great. Not sure if it is a normal issue because files are open in binary or not... JFileSystem therefore offers a "readIntoString" function that needs to be used instead of the usual "getline" technique. However getLine can then be used on a stream connected to the string.
-- tested on Windows and PSP, I also made sure android still works, but haven't tested zip support on Android.
-- I tried to maintain backwards compatibility, but this might break on some platforms, if I broke some platforms and you can't find a way to fix them, please contact me and we'll figure something out
-- This removes wagic::ifstream. I didn't reimplement the securities that were involved in this, apologies for that. Might be useful to reimplement such securities in JFileSystem
-- I haven't tested options/profiles in a deep way, it is possible I broke that.
2011-08-21 09:04:59 +00:00
2011-07-27 14:31:27 +00:00
2011-06-02 07:01:42 +00:00
2011-06-02 05:33:45 +00:00
2011-08-14 18:09:02 +00:00
2011-03-13 21:19:02 +00:00
2011-05-05 14:27:46 +00:00
2011-01-21 18:01:14 +00:00
2011-08-14 18:09:02 +00:00
2011-04-22 13:12:36 +00:00
2011-04-28 05:01:06 +00:00
2011-07-04 19:09:19 +00:00
2011-01-21 18:01:14 +00:00
2011-07-30 14:29:12 +00:00
2011-08-21 09:04:59 +00:00
2011-07-14 21:21:24 +00:00
2011-01-21 18:01:14 +00:00
2011-04-22 13:12:36 +00:00
2011-07-29 17:43:45 +00:00
2011-05-23 11:46:04 +00:00
2011-05-23 11:46:04 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-02-10 17:19:11 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-06-03 20:01:50 +00:00
2011-05-06 06:40:00 +00:00
2011-02-10 17:19:11 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-04-24 10:33:38 +00:00
2011-08-21 09:04:59 +00:00
2011-05-08 09:06:56 +00:00
2011-08-21 09:04:59 +00:00
2011-06-15 09:52:11 +00:00
2011-01-21 18:01:14 +00:00
2011-06-15 09:52:11 +00:00
2011-06-26 20:51:45 +00:00
2011-08-21 09:04:59 +00:00
2011-01-21 18:01:14 +00:00
2011-08-14 18:13:28 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-07-04 19:09:19 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-05-29 04:40:13 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-08-04 05:57:10 +00:00
2011-01-24 17:58:14 +00:00
2011-07-04 19:09:19 +00:00
2011-07-03 08:47:51 +00:00
2011-05-04 10:02:47 +00:00
2011-04-28 07:49:51 +00:00
2011-08-14 14:42:37 +00:00
2011-05-07 11:58:37 +00:00
2011-07-28 13:51:42 +00:00
2011-08-07 04:01:56 +00:00
2011-05-26 12:27:44 +00:00
2011-08-21 09:04:59 +00:00
2011-04-26 06:08:53 +00:00
2011-08-04 05:57:10 +00:00
2011-06-02 07:01:42 +00:00
2011-01-21 18:01:14 +00:00
2011-05-24 03:46:06 +00:00
2011-01-21 18:01:14 +00:00
2011-03-13 21:19:02 +00:00
2011-04-23 08:43:34 +00:00
2011-04-20 07:50:00 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-05-10 17:08:08 +00:00
2011-01-21 18:01:14 +00:00
2011-06-02 05:33:45 +00:00
2011-01-21 18:01:14 +00:00
2011-08-14 18:09:02 +00:00
2011-04-29 17:30:57 +00:00
2011-04-20 07:50:00 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-05-10 17:08:08 +00:00
2011-06-02 18:27:00 +00:00
2011-06-04 16:22:45 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-01-21 18:01:14 +00:00
2011-01-21 18:01:14 +00:00
2011-05-16 23:19:08 +00:00
2011-01-21 18:01:14 +00:00
2011-07-07 11:39:06 +00:00
2011-05-26 12:27:44 +00:00
2011-07-03 08:47:51 +00:00
2011-01-21 18:01:14 +00:00
2011-01-28 06:00:51 +00:00
2011-07-27 14:31:27 +00:00
2011-01-28 06:00:51 +00:00
2011-01-21 18:01:14 +00:00
2010-02-27 18:49:03 +00:00
2011-01-21 18:01:14 +00:00
2011-08-21 09:04:59 +00:00
2011-04-20 06:27:44 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-04-12 20:54:34 +00:00
2011-01-30 11:14:36 +00:00
2011-01-21 18:01:14 +00:00
2011-01-31 10:24:06 +00:00
Resuming on my threading support work with the card caching mechanism. This change unfortunately touches quite a few files, but I needed to get it out of the way before things got out of hand: one significant hurdle is the assumed lifetime of a JQuad pointer. In a single threaded model, the life time of the pointer is clear: you fetch it into the cache, the cache makes room, you use the pointer immediately. In a multithreaded context however, it's unsafe, as the drawing thread can request a few JQuads, and the cache operating on a separate thread can potentially bounce a JQuad out of the cache before the draw routine is done using it, which ends up in an access violation when you attempt to draw using an invalidated quad pointer. To prevent this, the bulk of this change swaps out the use of naked JQuad* pointers in the code with a JQuadPtr, which is basically a typedef to a boost shared_ptr<JQuad>.
2011-02-01 10:37:21 +00:00
2011-08-21 09:04:59 +00:00
2011-08-21 09:04:59 +00:00
e27cf56fa2