Mumbles

He is on Pacific Time, and on a day like today - he might still be in bed...

Even with a garbage collector, I would always favour tracking all my entities and freeing them only when I wanted to. Thus in my case, there shouldn't be any leaks on my part. If you lost a reference to an entity, then yes it may as well be deleted because you can't reliably get it back, but I would say it's poor design to get into that position in the first place.

If speed is really important, you can get a bit more speed out of it by replacing all of those calls to AppSpeed(). Saving AppTime() into a variable at the start of the loop, and just referencing that variable for the rest of the loop. Generally referencing a variable is faster than calling a function. Although, on a project as small as this, you won't notice any difference at all.

Do you have to set the gadget text inside the loop as well? This wouldn't make it get progressively slower though, so I don't know I'm afraid. But if it's not necessary, then it will be adding to the slow down (however marginal)

I don't know BlitzMax syntax, but it looks like you're creating lots of gbuffers possbily losing references to the old one Is there any reason your WaitEvent() and select EventID() lines are inside your repeat loop? What would happen if the were before the loop?

Orders are processed manually. So it depends if Josh has given himself the day off I suppose...

Was the image created using Josh's DDS converter? If not, try using that.

Clearly, I must have been tired last night when I uploaded, as if you actually try writing anything to files, you'll notice it has 8 bytes shoved in front. Which gives everything but strings (larger than 8 characters), a value of zero (and strings have their last 8 characters trimmed). The issue there comes from adding size checks to banks to prevent reading or writing out of range (which causes a crash). The same check was put on files when it shouldn't have been. All in all - not a brilliant start... (And I should edit this message to point out that it is now fixed)

Slightly more in-depth: Using the file commands requires a pre-opened ifstream or ofstream object (depending if you are reading or writing). Passing a stream that doesn't have an open file will not the application to crash, but nothing will happen. Banks are blocks of memory that are allocated to your application. You can allocate any number of blocks as long as the total system memory isn't exceeded. Reading or writing outside of the range does not cause the application to crash, but nothing will happen. You might want to use these, if for example, you want to extract some data out of a custom package file, and don't want to extract it to disk, read it with your application, and then delete it again. The number returned is the address in memory, but it's not a pointer type, so you can put an address of one bank into another one, and create a list of variables. The addresses are presented as 64-bit, but as it's not compiled on a 64-bit system, you'll only be able to use up to 4GB. Assuming you've got that much going spare anyway. 64-bit is used now so when it is compiled for 64-bit, anyone using this doesn't have to re-write these bits of code to reflect the change. The Ticker can only calculate the number of expected ticks if you tell it what the current time is. If you're using tickers, make sure you call the static UpdateTime method. You can either pass in the time yourself, or let the ticker obtain its own time. You might want to use a ticker to limit playback to just 30 fps. I can't think why anyone would do that, but it's possible. Alternatively they can be used in FPS games to control how fast a weapon fires. If the application slows down for a moment, the ticker will inform you of how many shots were missed due to the lag. String helpers are probably going to be the least useful part of the lib. They look at strings and retrieve individual words, substitute words (Could be combined for a little kids swearing filter). Strings can have a certain character trimmed from the start, and the end of a string. The only useful part of the string helpers is being able to convert numbers to strings, and vice versa. Anyone thinking it might be useful, and wanting examples, just ask...

File Name: MumblesLib File Submitter: Mumbles File Submitted: 24 Dec 2009 File Updated: 05 Jul 2011 File Category: C/C++ A fairly unimaginative name for a relatively simple library. Maybe someone might find it slightly helpful - and since it's christmas, why not make it available to anyone who wants it? The library came about as I migrated from Blitz 3D to C++. With only a moderate knowledge of Java's syntax, I decided to write a library that would simplify binary file I/O operations, as they looked quite daunting. Since then various other features have been added, and are as follows: File I/O: Read and write any primitive data type to files on disks. Reading and writing of std::string objects are also supported. Banks: Similar to above, except with chunks of RAM instead (Addresses are 64-bit, but is compiled on 32-bit windows. This is so projects using this do not have to be re-written when I upgrade to 64-bit). String Helpers: Retrieve individual words without having to go through a tokeniser first. Also converts numbers to std::strings and vice versa. Tickers: Timers that count how many times an action should have been performed within a given timeframe, or simply act as speed limiters. All should be working if used in a release build, but obviously, I'd like to know of anything that doesn't work properly, or at all... besides that, I hope someone has a use for it. Update: 2011/07/04 -- 22:44 GMT Version 1.1:1 Over a year has gone by, and this project has been improved several times since then. If anyone is actually using this, there's an update you may like: The concept of banks has been totally overhauled. Before they were only designed to be small blocks of memory. Now you can allocate insanely large amounts of memory. Before this update all banks were continuous single chunks of memory, so if you were to allocate more than a gigabyte your system may have started to struggle. If you then wanted to make that bank even bigger, it would have been a nightmare. But now, a single bank can be made up of multiple chunks of memory. You can easily allocate 1.25 gigabytes on 2 gigabyte system. Then resize it to 1.5 gigabytes and still have all of your existing data preserved. The resize operation is also a lot faster than it used to be... Also added is the ability to write any custom structure or class to a bank or to a file: Use PokeBytes to write your structure to a bank. Give a pointer to your structure as the DataPtr and the size of the structure as the DataLength, and your structure will be saved. Use PeekBytes to read it back from a bank. DataPtr is where the structure will be written to (so allocate the memory before you call PeekBytes), again you must specify the size of the structure to be read. To save your structure to a file (and read it back) use WriteData and ReadData in the same style as PokeBytes and PeekBytes. Since the last update, the Ticker class now has millisecond accuracy (Many thanks to Lumooja for that one: http://www.leadwerks.com/werkspace/topic/3006-timegettime-identifier-not-found/page__view__findpost__p__27937) (Last updated 2009/12/25 -- 22:44 GMT ... Version 1.1:1) Click here to download this file

That's true for a linux user, but not for your typical windows user. If people weren't running their regular accounts with admin privileges, UAC would probably never have been born. There just seems to be something in the transition of becoming a linux user that makes you realise the potential danger of running with elevated privileges. Of course, not every windows user is guilty here, but the vast majority.

I use the engine as if it were plain C, and my content for a project is mostly C++