How to do something while files are loading?
BlitzMax Forums/BlitzMax Beginners Area/How to do something while files are loading?
| ||
| How could a given BlitzMax programmer go about having something occur on-screen continually while a file is loading? From what I can tell, when you load a file, say a picture or a datafile or something, nothing else can happen until the file is fully loaded? I ask because it used to be a very popular feature of games to DO something or show something while data is loading, e.g. a spinning disk, some small animation, or even continue with the full gameplay like in Swiv. How would somebody spool level data from disk in realtime while a game is still running? |
| ||
| There's the stream.bmx module. I haven't really fiddled with the mods, but if you're game ( and indeed you seem to be from other forum posts ) perhaps you could point the stream command to a local file instead of a web url? |
| ||
| Hmm I was wondering about those streams. I figure they are buffered so probably the o/s handles the buffering, which makes it partly parallel to the app running... Maybe if a very small chunk of data is loaded per frame it would work out ok? |
| ||
| Maybe if a very small chunk of data is loaded per frame it would work out ok? Yeah, I guess a certain amount of trial and error would be involved to see how much data could reasonably be streamed from the hard drive per frame without impacting on performance. Ideally you'd want a nice low end machine with a slow hard drive to see how it copes. |
| ||
| You'll need pre-emptive Multithreading for that one. Problem is it can be somewhat challenging doing it properly accross 3 different platforms. |
| ||
| Isn't purebasic availiable for four platforms now? That has great threading support. Bmax won't be taken seriously otherwise. You explain to Publisher B why you can't stream in media without crippling your program..'Oh mark thinks they're not required' 'Mark? Who the hell's mark! You're fired'. (Though saying that, I don't see mark himself has to code this.. There seems to be enough power in bmax to do it direclty within it, using a touch of C++) |
| ||
| Threading is likely to be a mess if you want cross platform, but easy in windows. I would just update the loading bar or whatever in between each loadimage or something. Is there a cool way to hook into the blitzmax modules so we can have the system call Loading() after anything is loaded? Seems like an easy peasy way of doing stuff. |
| ||
| >I would just update the loading bar or whatever in between each loadimage or something. yeah, it's not like you are going to be loading 2 GB jpg/png images so you need to have animation updated while single image is loading. Update the animation between uploads, problem solved... |
| ||
| Antony If you're using a Basic dialect, you're going to have to give some things up. Threading is a very advanced topic, rife with pitfalls and weird problems that are very hard to debug. I doubt Mark wants to go there, especially seeing as even something as simple as expecting users to type their variables names in the proper case is seen as "too advanced". |
| ||
| >case is seen as "too advanced". perhaps "unneccessary" is the right word. Max is too Advanced already! |
| ||
| A loading bar? I would like more to be happening than some dumb `everybody's done it` loading bar |
| ||
| Antony If you're using a Basic dialect, you're going to have to give some things up. Threading is a very advanced topic, rife with pitfalls and weird problems that are very hard to debug. I doubt Mark wants to go there, especially seeing as even something as simple as expecting users to type their variables names in the proper case is seen as "too advanced". You're right of course. Personally I'm waiting with baited breath the update that finally gets rids of types and variables all together. seriously though, Purebasic DOES support threads(I have it)..I even did streaming data functions for blitz3D in purebasic. As it even supports them in .dll function calls. Ironically another thing bmax sorely needs. I mean, you can argue most users won't need them, and that's correct. But what about the users expected to write the libraries that will make or break Blitzmax.(Mark's 3d engine alone won't replace the hundreds of great libs C++ has. And since these people can't use threads, surely they can't write C++ glue...) Anyway, too much talking, think i'll just try it myself..For windows at least. |
| ||
| It's not full threading support that's needed here, just for the load commands (or a variant of the load commands) to be (optionally?) run in a separate thread. For example, to be able to do if LoadImage had a 'streamed' parameter, deafulting to False, and then have a new IsImageReady function / method which the user is responsible for checking. e.g.
img1=LoadImage("image1.png",true)
img2=LoadImage("image2.png",true)
' etc
Repeat
'draw animated loading page here
Until ImageReady(img1) and ImageReady(img2) 'yuck, this could get enormous...
'start the game...
I have no idea whether this is possible, or practical, but sounds like it would be damned useful. The complexities of the threading being hidden away in mark's C code, rather than 'max. Thinking about that yucky syntax, how about:
stream=CreateThreadedStream() ' you know what I mean!
img1=LoadImage("image1.png",stream)
img2=LoadImage("image2.png",stream)
' etc
Repeat
'draw animated loading page here
Until EOF(stream)
'start the game...
|
| ||
| Multithreading would be nice but no publisher is going to give a toss about having an animation while a file is loading. That's just daft. And BMAX is already taken seriously. |
| ||
| Streaming media exists not for the glory of the loading bar. It exists for the glory of innovatie 3d worlds with no loading breaks, no seems. And that's just the tip of the iceberg. Angel, you can do an extended tstream class and hook into the streaming variables and inc a counter in them.
Type TStreamFeedback Extends TStream
Method StreamData() 'Or similar
cp=Streampos (ThisStream)
Super.StreamData() 'Call original stream
YourCounter:+StreamPos( ThisStream) - cp
End Method
End Type
Super lets you call an overidden method, allowing you to mod them without rewriting..perfect for what yo want unless i'm overlooking something. |
| ||
| But they might give a toss about a game that has no discernable loading times. And static loading screens still smack of a "can't be bothered" attitude IMHO. e.g. during those dull branding exercises at the start of every game nowadays, why can't the game have loaded already in the background? (pet peeve) In any case, I'm disliking what I wrote above more now that I wonder about how you handle exceptions without proper multi-threading... |
| ||
| I've been working in development for 20 years and no publisher has ever expressed an interest in loading animation. Developers tend to care more about it out of pride more than anything else (which I agree with of course). I'm just responding to Antonys scare-mongering. Very few games bother with multi-threaded loading. I wonder it's possible to automatically have file loading commands work on a separate thread. With a simple waitforloadingtofinish command? |
| ||
| So, in your opinon threading does not offer a huge array of advantages over 'linear' code? It's no surprise all the emerging cpu tech set to replace x86 once and for all is completely based around multi-core/multi-threaded/distrubated(I'll spell that right..one day) processing. The future is not coming, it's already here...(you-re fired.ed.) And btw, i'm not scare mongering. I've said it before and I'll say it again, bmax is the best language out there right now. if it had threads/lib creation support(I.e dlls/.libs) i'd never need to use c++ again. |
| ||
| Perhaps something like Flash 6's file loading system. A class that spawns a new *private* thread (so you don't have syncing issues) and contains a public function that will return how much of the file is loaded and a pointer to a function that will execute when done. Maybe another function that waits until the file is properly loaded. That could be useful for a number of things, not only file loading. Should be properly portable too. |
| ||
You can have an animation playing while loading in bmax, heres how ...setup memory bank, size of file loop read in a <a number of> bytes of the file to memory bank update on screen animation until whole file loaded load the file from memory instead of file now Whats the problem in doing that?, people making a mountin out of a mole hill I say. |
| ||
| oh yeah - because you can use :: for incbin loaded stuff can't you? And you can loadimage from the bank. I imagine it will slow down loading - but only slightly if done right... nice tip shag. |
| ||
| Streaming worlds is a great feature, but it's going to take a lot more than adding threads to BlitzMax to make it happen. It's a lot more work than I think people are giving it credit for - the language really needed to be built with it in mind from the start rather than trying to tack it on now. BlitzMax2 is probably your best bet for this. :) |
| ||
| Maybe a useful feature would be to add support for creating additional processes and then allowing inter-process communications. It doesn't have to be fancy thread stuff. Then you can spawn a process to load files to a given memory buffer or whatever and meanwhile your game can continue doing something more useful. If GUI's had no multithreading you'd be sitting waiting all the time for things to happen, rather than the GUI code being given a higher priority than other things. It wouldn't be responsive. In my view of software design, delays of any kind are unnatural and unacceptable. There is a lot of wasted time inbetween useful code that is wasted, as far as the user is concerned, waiting for stuff. Indeed, another example would be that you have some intro animation thing which gets loaded then executed, and while it's running you should at least be loading the level data for the first level. Rather than waiting for the user to make selections in a menu you should be pre-empting their likely decision and loading stuff ahead of time so that their actual actions produce immediate consequences. It's actually dam annoying waiting around several seconds for something to load and being able to nothing about it. If a software publisher is not interested in how streamlined the file loading is and how often the user has to wait, I wouldn't use that publisher. And if it is a widespread attitude that it doesn't matter - maybe people need to do something to change that attitude. Until you show them how it can be done differently they might not even expect that it could be better. Time spent looping through a little routine waiting for the user to click on a menu button could be better spend doing all kinds of computations and loading of data. For BlitzMax, all you'd really need is a way to have data be loaded a little bit at a time and then be able to pause to do some processing. Streams sound ideal and maybe that's all we need. After all, if the disk access doesn't work with DMA (direct memory access) it will use CPU time. Even if you make things multitask with multiple processes or threads you still, actually, are probably only using 1 CPU and timesharing it. So you really only need a timesharing system between spending a little time reading data and spending the rest of the time doing stuff. I remember the shootemup Swiv on the Amiga which got a lot of attention for being able to continuously load level data and gfx without ever having to stop, for continuous scrolling action. That was cool. I would definitely want to be looking at parts of an app that are not making the most use of CPU time and try to use that time more wisely. |
| ||
| Also I don't really think it's entirely BlitzMax that makes it happen or not, it's up to the imagination of the programmer to come up with a way to artistically use the tools available to produce an acceptable result. |
| ||
| With regards to streaming worlds, take a look at Grand Theft Auto 3/Vice City/San Andreas on the PS2. Streaming world, no threading. Probably using Shagwana's technique. That method's good because you can always tell how much of your game loop is going to be take up by loading and you don't get it in spurts, killing your fps for a couple of frames. |
| ||
| You need threading. I tried the above approach in vivid, even created a format designed to be read in dynamically sized chunks...it crippled the framerate. Ps2 is designed around the concept of quick streaming data(High bandwidth, low memory), pcs arn't. |
| ||
| So, in your opinon threading does not offer a huge array of advantages over 'linear' code? I didn't say anything like that - in fact I'm in favour of threading. I dispute that you'll EVER find a publisher that gives a toss or that Blitz needs this to be taken seriously (it doesn't). |
| ||
| Well then the important thing is we both want threading. We're all going to have own reasons for that, no point in a 'dispute' over it. |
| ||
| I remember the shootemup Swiv on the Amiga which got a lot of attention for being able to continuously load level data and gfx without ever having to stop, for continuous scrolling action. That was cool. I would definitely want to be looking at parts of an app that are not making the most use of CPU time and try to use that time more wisely. I only recently found out it was done by the same guys who did Saint Dragon earlier, too. I loved that game. Wicked soundtrack. Soul Reaver and obviously GTA should be given recognition here too. I think Jak & Dexter as well? What was that platformer done by the guys behind Crash Bandicoot? Ps2 is designed around the concept of quick streaming data(High bandwidth, low memory), pcs arn't. So the PS2 doesn't support threading? I had no idea. Anyway, yes, Antony's comment above is very apparent by playing the same GTA games on the PC ;] I dispute that you'll EVER find a publisher that gives a toss or that Blitz needs this to be taken seriously (it doesn't). How many publishers take a BASIC derivative seriously at all??? |
| ||
| So the PS2 doesn't support threading? I guess it's upto the developers, as ps2 is so low-level. I mean Threading on most pcs is done in software by windows. The ps2 doesn't have that layer of abstraction to rely on, so I guess a game can implement it directly.(No doubt alot better than ms' goons can manage) |
| ||
| How many publishers take a BASIC derivative seriously at all??? I doubt very much they care. The ones I've had dealings with certainly didn't, and that did include a couple of big publishers. IIRC, JP's Future Tactics was originally written in B3d before being ported to C++ and Renderware, so I guess it didn't bother his publisher either. Ps2 is designed around the concept of quick streaming data(High bandwidth, low memory), pcs arn't. Fair point. Consoles tend to have everything on the same bus which makes it much easier to move things around without slowdown. |
| ||
| Publishers probably care to a certain degree which language you use simply for support issues, but it's going to be WAY down on the list - far below things like "how much money will it make?" and "how close is it to completion?" |
| ||
| I don't have experience with publishers but I would say it doesn't really matter what languages you use so long as the end results are impressive, it's bug free, it works like it should consistently and can be easily maintained or added to. You don't exactly see a label on the box of some software saying in sparkly letters "written in c++!". |
| ||
| This is because C++ has constantly delivered the goods. Blitz3D isn't quite up to the task (although impressively close). Blitzmax might even change that but it's unlikely blitzmax will be embraced by developers as C++ / renderware is just too good because they can develop for pc, gamecube, ps2, etc all at once. Mac and linux are tiny markets compared to consoles so there isn't any wonder why C++ is dominant. Another major consideration is that C++ programmers are everywhere for hire. Blitzmax will never be the choice for big studios - ever. But it could find a niche with medium and smaller software developers. I would not be suprised if one day a decent PC RTS was released by a fairly large house made entirely in Blitzmax. |
| ||
| I think Blitzmax has the potential to be something amazing, and that something is the best language for writing games, C++ or not. But whether it fufills that promise that is down to whether mark starts releasing updates for the core language(I.e bonefide improvements to the compiler/language it's self, not just useful modules, which anyone can do, thankfully) and doesn't let the b3d trend of 1 or 2 updates a year carry on.(Way too early to determine yet...it's not even out for 2 of the platforms.) The only way is up...if mark wants it. |
| ||
| The Velocity engine that the comapny I was working with for PS2 and Xbox had great streaming capabilities. It was a TPG in the baldurs gate mould and the rooms were streamed off of the DVD as you walked around. Initially the technology was developed for the artists, so the PS2 could compete with the favoured Xbox platform as prior to streaming levels you would have to reboot the PS2 test station and re synch it to a PC every time you wanted to view an updated piece of artwork, With streaming you simply walked out of the old room so that it was outside of camera view, next time you walked in the new version of the artwork was there. No PS2 reboots, synching etc, and saving valuable minutes (particularly with the poor quality of the PS2 dev kit and test kit components) It doesn't sound like much but it is really cool to be able to stream data straight off the HD, or DVD. A real shame it isn't used much as its one of the Xbox's particular strong points. |
| ||
| SSX tricky and clones on the ps2 used great streaming abilities. They streamed an entire mountain full of miles of data. With pc, mac and linux you can hold the entire mesh data in memory - probably something like 10 megs. This is impossible for current consoles but easy for even the smallest laptop. Streaming has a place - but it's not a vital one (unlike consoles) |
| ||
| SSX would have to have been the first major streaming title for PS2. Not sure about how much of the gfx it streamed but the music for SSX and SSX Tricky was fully interactive (not an easy feat for mp3 style audio) and I could tell speech samples were being loaded in at stages too. SSX 3 is incredible. Once you unlock the entire mountain it takes no less than 25 minutes to ride down the thing, so there is definate texture/model/music/sfx/major major streaming being done in that game. GTA San Andreas. Nuff said. Soul Reaver was probably the first streaming PSX title I'm aware of, although I'm sure there were probably lesser titles before it. Two completely continous chunks of land being played on semi-simultaneously (the terrain deforming from spiritual to physical worlds were near-instantaneous. If the mesh co-ords weren't both being streamed in at the same time, they certainly had some really effective indexing going on, file wise... can't remember if the music was streamed or not tho, I think it was realtime/module based). My point? Streaming games are cool. =] |
| ||
| IMHO: threading (and IPC) is essential in any language. You'll need/want/miss it sooner or later. I'm not familiar with console development so I'd be pleased if someone could tell me how streaming offers an alternative? Re original post: a progress bar type indication, afaik, has always been considered essential for two reasons: to indicate that the program hasn't just hung and also to distract the user during long load times. Attempting (and failing) to do this in PB and my own little gfx engine leaves me thinking it is easier/saner to provide a seperate program(-let) for this purpose (at least for start-up loading which was/is my requirement). PB's threading is basic (no pun intended) and is a nightmare where strings are concerned. Interesting: [URL]http://sources.redhat.com/pthreads-win32/[/URL] |
| ||
| There is one thing where already BB3D showed why threading would be needed: The Terrainsystem that really s**** It is nice sure ... but updated far to often taking away performance like hell with 4000 triangles and similar just because its update depend on the frame rate ( -> lower frame rate made the terrain even worse for performance ) Terrains, streaming and realtime data gathering ( loading while playing for example ) and similar stuff just NEED to run asynchron to the gamelogic as they follow their own logics. Sure it can be "faked" in some cases using timed execution but in that case it just blocks other stuff from the core gamelogic. I don't know how hard it would be to implement but it is a feature that has to be done before 3D module should be started as several things in that module depend on threading in a "real" scenario |
| ||
| Maybe a useful feature would be to add support for creating additional processes and then allowing inter-process communications. It doesn't have to be fancy thread stuff. The advantage threads have here, is that they share common data. So one thread could be loading data into the same images, the main loop uses for rendering. You don't need to do expensive memory copies inorder to access your data. There is a lot of wasted time inbetween useful code that is wasted, as far as the user is concerned, waiting for stuff. That's not even the worst bit. Since BlitzMAX currently only works on pre-emptive timesharing OSes all of which support multiple processors, you're wasting a lot more than that! Have a Dual 1Ghz iMac, or a Dual pipeline HyperThreading Pentium? Well you're only using half of it's potential processing power, while the rest is laying dormant, doing menial maintenance tasks for the underlying OS. So the PS2 doesn't support threading? Anything can support threading. With pc, mac and linux you can hold the entire mesh data in memory - probably something like 10 megs. Yeah, so I guess the 900 Megs of textures is probably where the real need for streaming arrives. Look at World of Warcraft for an excellent example. Why someone commented just the other day how "You don't really notice the lack of loading times, until you play EverQuest 2".Real-time games are (or should be) an integral part of future gaming. No-one wants to go through the 15-minute horrors of load times that is Battlefield 1942, DOOM 3 and HL2. Especially since it's not nessecary! Most people have at least a gigabyte of RAM nowadays (certainly serious gamers), the development team clearly had loading in mind when they designed the level, notice all the bendy corridors, supposed to give you a natural transistion, natural that is if it wasn't for the 6 minute "Please Wait ... Loading" intermission you get every once in a while. People always talk about how games need to be more realistic, and immersive. Well getting rid loading screens (and animations for that matter) is probably step one. Re original post: a progress bar type indication, afaik, has always been considered essential for two reasons: to indicate that the program hasn't just hung and also to distract the user during long load times. No. It's been considered essential because of lack of vision. Terrains, streaming and realtime data gathering ( loading while playing for example ) and similar stuff just NEED to run asynchron to the gamelogic as they follow their own logics. Physics too. |
| ||
| People always talk about how games need to be more realistic, and immersive. Well getting rid loading screens (and animations for that matter) is probably step one. A bit of a spiraling problem though. As soon as hard drives get fast enough to pull the data into memory fast enough, the content moves forward (aka gets larger) and we're back to "Please wait..." messages. Streaming is great, but if you're moving too fast through the world, there's going to be a pause. Unavoidable. GTA and it's ilk are great examples of streaming, and if all games could use that level of detail it would be great. But as soon as you start introducing high resolution textures and high poly meshes, it becomes a harder problem... No. It's been considered essential because of lack of vision. Still in school, huh? :) |
| ||
| I remember playing Shadow of the Beast .. .you were running along mid-action and then all of a sudden things would freeze, you might happen to notice some disk access, and then could continue. It wasn't entirely elegant but I guess we put up with it, but it is a little distracting. All the opinions flying around as to whether its right or not to have loading screens or not, or loading animations or not, or whatever, is really not important. Anyone can create whatever they want in whatever way they want. If I want to have 16 loading screens I will have em. The question isn't whether it's right or wrong to use a certain design, that's entirely personal taste, the real question is how to do what you want to do in a good way. Ideally the language you use can let you do exactly what you want to do, otherwise you're reaching the limits of the language. I think it would be cool to be able to load files `in the background`. That's just me. |
| ||
| I don't know how hard it would be to implement but it is a feature that has to be done before 3D module should be started as several things in that module depend on threading in a "real" scenario I agree 100%. Mark has stated that he intends the Max3D module to be a 'next gen' engine, which means all the classiest features OpenGL has to offer, much more advanced than the B3D/DX7 engine was. Streaming or threading (I consider them to be the same thing where file loading is concerned) is a must for such a next gen engine. It -cannot- be overlooked... So the PS2 doesn't support threading? Anything can support threading. Yeh but I meant more as an OS thing. I know anyone can code their own interrupts and do it themselves. AmyBlitz was great for that. 15-minute horrors of load times that is Battlefield 1942, DOOM 3 and HL2. Really? HL2 has shocking loading times? That's a rather large shame. The original HL was fantastic for loading times. Lots of small bits of level rather than a few big levels were much less unenjoyable to sit through... GTA and it's ilk are great examples of streaming, and if all games could use that level of detail it would be great. But as soon as you start introducing high resolution textures and high poly meshes, it becomes a harder problem... GTA Vice City on the PC was a nightmare though. Really screwed up streaming in that game. Much too slow. You don't even need a fast car to drive into an area that is semi blank (basic road layout is there, but none of the collidable objects are visible yet, and then bang! You hit nothing and -then- it shows). The strange thing was it was mostly completely avoidable. Their streaming cache was hardcoded to 45 megs. If you use a 3rd party app to change that hardcoded value, to say, 128 or more, the game ran much more smoothly. Decisions like that just don't make any sense... It wasn't entirely elegant but I guess we put up with it, but it is a little distracting. Well yeh Miggy owners tended to instinctively know that mem limits could pose problems like that and we put up with it. Which is exactly why a game like SWIV was so popular. It wasn't a particularly good shoot em up. Silkworm 1 was much more fun imo. I think it would be cool to be able to load files `in the background`. That's just me. While I agree with you in theory, I don't think there's a person in the world that would consider a loading screen as 'adding' to a game =] |
| ||
| The PS2 certainly does support threading. Future Tactics used it for the AI. No publisher I've come across has ever asked about the language a game was written in. You'd have a hard time finding anyone who cares. If the game is good and marketable then they will want to publish it. I'd love to see threading but I haven't found anything I can't do (apart from load stuff in the background) with more conventional coding. All games programming involves splitting tasks into tiny chunks which is essentially a manual form of threading anyway. I don't see any reason why Blitz Max coudn't one day be the language used by a 'major' dev studio. Not all programmers are blind C snobs. Wasn't Jak & Daxter written in another language (Lisp)? Using in in-house compiler? While I agree with you in theory, I don't think there's a person in the world that would consider a loading screen as 'adding' to a game =] There's a lot more uses for background loading than animated loading screens. If done well (see many Gamecube titles) loading can be hidden totally. |
| ||
| Multi-threading is over-rated. I've used threading quite a lot, yet I don't think I've ever come across an instance where I've absolutely needed to use it, or where the application would be 10fold better because of it. Threading is good for fixing up procedures that block by nature, but you pay for it in code readability, code maintainability, and with the thousands of bugs you inevitably introduce when coding asyhchronously. - And no that's no just me, deadlocking it's a common problem that's a thousand times harder to debug than issues that arrise in syncrhonous code. That's not to say that threading isn't good, it's just to say that you are wildly overstating it's usefulness. Max needs 3D and a whole host of other things, before it needs threading. |
| ||
| And the terrain system needs threading. The old one was a horror when it comes to "needed cpu time / result" ... it needed a lot of time and looked crap ... if a 200'000 poly terrains runs faster than a Blitz3D Terrain with 7000 and looks better then the point is reached where something should be done ... Physics did not suffer by this as they had their own thread due to the nature of their DLL userlib-ness but in blitzmax with crossplattform the problem with threads will most likely reappear as well. sure threading is not needed for rendering but for quite some stuff "behind" the scenes were large things happen |
| ||
| I'll be releasing a thread lib for windows shortly. have threads running fine. |
| ||
| You don't need threads to load media in the background. All you need are asynchronous file operations, which are found in all popular OSes. You perform a file read, then each frame you check to see if it has completed. That's all. |
| ||
| junkster: very good. and this is done over threads / processes |
| ||
| I don't think I've ever come across an instance where I've absolutely needed to use it, or where the application would be 10fold better because of it. Then why have you been using it alot? Good examples of everyday examples where threading will make your program 10 fold better because of it:a) SmartDraw: This somewhat useful tool for drawing schematics has several gigabyte of useful chart types that it can use. Since it doesn't want to bloat too much on your harddrive, as a convenient way to perform updates and possibly as a measure to prevent widespread piracy, SmartDraw will download these modules of an Internet Server. In a seperate thread. This means that while you're downloading the latest update or new plug-in you can continue to use the program. b) Eclipse Project: The mother of all IDE's contains an auto-build feature that will re-compile out-of-date classes silently in the background once they're altered, thus allowing you to continue programming, and speeding up the actual compile process by far more than a factor of 10. (Since compilation time for the most part will be 0 as everything is already compiled). c) Large scale multiplayer games, should create seperate threads for each client connection. That way the OS task scheduler will be better able to handle the many connections, and your game will get a significantly larger hit percentage. Oh and you'll be able to use Blade servers. And no that's no just me, deadlocking it's a common problem Only if you use Semaphores. Max needs 3D and a whole host of other things, before it needs threading. Surely that's objective? I'm sure someone who doesn't want to do 3D couldn't care less about 3D. Incidently support for threading will have to be added to make a good GUI anyhow, so I'm not particularly bothered. I'll be releasing a thread lib for windows shortly. have threads running fine. How are you handling syncronization? |
| ||
| Just wanted to point out that Half-Life 2 also has static loading screens ... which become animated once the game is done loading. |
| ||
| hehe ... HL2 even has some playing between loading sometimes ( in the stuff with the speed boat I was more loading than playing ... 40-50s per part and 2-6mins of loading ) Perhaps it was that what you meant with animated loading screen? ;) |
| ||
| How are you handling syncronization? Protected data using windows mutexs. You can spawn threads from bb wrote functions, so you can access shared data blindly, but the protected approach is better(And managed for you by a master thread, you just request variables, and release them when done) |
| ||
| 3D games like topdown/Iso style 3D games in BLitz3D would have benefited greatly from streaming levels, as only chunks on screen need be loaded and in ram at any time. Might help alleviate some of the surface count and entity count problems that surface on lower spec machines. A lot of level loading anims actually pause and update between HD file reads and arent true streaming at all. Most people here might not have any intention of making a high quality publishable game, but those that do can probably find all sorts of uses, even if its simply to reduce hardware requirements on lower spec systems with streaming meshes and textures/brushes and enhance the quality of games. I know this is the Bmax forums, but this would have been really handy for several Game ideas I had in mind for Blitz3D. |
| ||
| You do not need high quality game at all. ok for streaming loading this might hold ... but Terrain and Physics are needed for many types of games and they greatly benefit ( or even depend ) of several processes / threads for an optimum or work as wanted in some cases ... |
| ||
| Let's say I have a simple 2d game with a tile map and I want more map to load in realtime while the game continues to run smoothly, without stopping, how would I do it in Blitzmax as it stands right now? That's more the question that was originally being asked. |
| ||
| 2d game? Just load the whole map at start into an 2d array ... you will use bytes or ints in your fileformat anyway ... and I don't think that a 2D map exists that exceeds the RAM of a regular pc ;) |
| ||
| talking about loading more graphics too, not just the map data. Lots of animations, lots of mem, needs to be spooled. How? |
| ||
| Wasn't Jak & Daxter written in another language (Lisp)? Using in in-house compiler? They started using an inhouse version of Lisp since Crash Bandicoot 1 and never looked back =] There's a lot more uses for background loading than animated loading screens. That's exactly what I meant. My quote was aimed towards AngelDaniel saying something to the effect of 'loading screens are OK so long as it matches the teams vision for that game' =] I was just saying I don't care how cool a programmer may think their loading screen is, I don't think there would be a gamer in the world that wouldn't prefer no loading at all! |
| ||
| http://lib1.store.vip.sc5.yahoo.com/lib/paulgraham/jmc.lisp lisp looks *horrible*. |
| ||
| @skunk Yeah, but it's got a lovely personality ;) |
   |