Project PLASMA FPS 2004: Thread 5
Blitz3D Forums/Blitz3D Programming/Project PLASMA FPS 2004: Thread 5
| ||
| Project PLASMA FPS 2004: Thread 6 |
| ||
| Just an Update, I've been multitasking between writing code and documentation. Check out the TODO List in the documentation. I'm very very busy to say the least. The 'engine' core in its final stages (minus networking). My goal is to put together a demo that will demonstrate all game objects and special fx basic functionality. New features can be added later. The engine code is very modular. Some would say there are too many modules. However, I have separated 'game objects' based on common properties and specific purpose. I have consolidated objects with similar properties into one. Many of the game objects can be used in other genres. I will be removing the separate entries from the code archive to pack all the code and media into one clean zip for download. More to come... |
| ||
 Reactors! Check the online docs under SpecialFX Objects for details. |
| ||
| It appears this is just an emitter/particle system? If so, are you doing this in a single-surface manner (e.g., one surface per emitter or one surface per 4 textures or so- I think you get the idea)? Looks very, very red, at any rate. |
| ||
| Noel Cower, Currently, a non-single surface system to support meshes > 2 triangles used in ammo etc. However, I've have plans to move all sprite-based particles to a single-surface system - research in progress. The particles are very basic. I intend to improve with spiral/helix movement and blending. |
| ||
| Don't bother moving it to single surface or plasma will never get finished.. Finish plasma then optimise the hell out of it after. |
| ||
| Indeed, the particle system for stormfactor is some 1500 lines. use the time you could to write a single surface system and instead focus on important things. Particles are not important. (Until you have something more to show.) |
| ||
| The "Waypoint Editing Utility" isn't working right ? Is there a working one somewhere ? |
| ||
| Chi3f Stadi, Oops, Ive been meaning to rewrite it. Its low on the priority list at the moment, so, I will most likely not be updating for some time. |
| ||
| Computer Crash:( I'm currently out of commission until I replace my PC motherboard. I anticipate being back in business within a week or two. |
| ||
| Anyway, the particles look nice. |
| ||
| I've made a new track. Hope you like it, and hope it can be used for Project Plasma. Fight for Life Oh, and by the way, you might as well take the other track I've done off the list of tracks for Project Plasma. I currently feel that my inspiration is leading me to do other tracks than that one right now, so I've shelved the incomplete one in favour of the above one (which is complete). I'm not saying I won't finish the incomplete track, it's just that currently I feel that I'm going nowhere with it, and so I think it would be best if it wasn't up there until complete. It may be complete someday, but then again, it may never be. Anyhoo, tell me what you think about "Fight for Life". |
| ||
| Ash, Thank you for your contribution and I'll make the changes. Unfortunately, my home computer is down at the moment. I can only use the internet at work. I should be in business within a week. Then I can give you some feed back. |
| ||
| I'm baack... |
| ||
| Good to hear Frank. Are all of the new/updated files listed in the first post? I need to get the site I'm hosting updated. I was hoping that members would upload the files as they came out, but no one has. I will be on a mini-vacation (at home, not going anywhere) later this week and so I will have time to update the page. |
| ||
| dangerdave, I've made attempts to ftp, but, no go:( As soon as I get my pc up to par, I will be back in business and well give it another try. |
| ||
| persistant project. kudos. |
| ||
| I wonder if that was sarcasm... |
| ||
| poor attempt at.. |
| ||
| If it was sarcastic I don't know why he said kudos. But it did strike me as being an odd time to post that =] |
| ||
| give it a break. the nurse with the defilibrator is just around the corner. |
| ||
| Speaking of breaks, I should be back to full operational status within a day or so. Unfortunately, due to disk drive failure some information is lost (mostly documentation). However, I'm ready to jump back into action. |
| ||
| CVS is good, CVS is great. You should get a CVS server- it'd be good in the case that you were threatened by potential data loss. Just a suggestion, though. jfk: Not all of us are sane, you know ;) |
| ||
| The PP2K4.zip (9.8M) has been updated. It is highly recommended interested parties download this file for current code, media, and documentation. NOTE: There are lots of new entries and some aren't documented at this time. Whats currently in the works: Platform/Door Code Network Code I will be revisiting the BotAI immediately after the preliminary Code above is in place. |
| ||
| Sounds good, but the network part is probably something more tricky, so maybe you have to work on it parallely to the whole project. (MP Event notification and handling) |
| ||
| jfk, Agreed. I'm pursuing a network design that will support both server/client and peer-peer networking. A great deal of research at the moment. My goal is to design a network interface suitable for traditional peer-peer link and persistant world. Heres a very good article on Unreal Network Architecture by Tim Sweeny. |
| ||
| I would like to discuss my current Platform design. Currently, I'm using a linepick to determine if the player is above or below a platform. If above|below, the player moves/rotates with the platform along the Y axis. This is ok for vertical movement but, requires more linepicks for horizontal movement and rotating platforms. My second design is to use blitz sliding collision and move/rotate the player along direction vector upon collision. Not quite sure how this will work. Waypoints are used to control Platform movement (allows for complex patterns of movement). Platforms can be activated/deactivated by triggering a Switch object. My goal is to create a flexible platform system and so far I believe I'm on track. Ideas welcomed. |
| ||
| I found platforms to be VERY hard and my current system (as seen in SECRET OF MANES) still has significant bugs. Probably it would be possible to simply parent the player to the platform while he's on it. Of course, gravity must be handled extraordinary to prevent the character falling trough the platform when it's moving upward. |
| ||
| I just downloaded it, it runs pretty awesome on my PC. I just have one thing that I would like to say, when I'm going up on an angle - the player slows a lot, that can be modified easily. Good job, and open source!!!!! |
| ||
| xmlspy, I experience the ramp slowdown as well. I suspect ramps to be very steep in some areas and this behavior is normal. If it becomes troublesome I will look for a method of correction. jfk, As you mentioned Platforms are tricky. I've managed to get a basic vertical lift working. I'm going to omit fancy control to press on with other game objects. |
| ||
| Progress update? |
| ||
| Anything at all? |
| ||
| Interested parties, Currently, Network Architecture is on the drawingboard. In retrospect, this should have been outlined in the beginning because the Server/Client design can significantly alter the current core code. Anyhow, I'm conducting some Research. I'm more in favor of Persistant Network design vs the typical peer-to-peer. In my opinion this will provide greater multiplayer functionality could possibly be used to support Massive Multiplayer. Ultimately, Players will be able to move in and out of the game at will. Game Admins could be able to provide realtime updates and changes. In my current design, the Server will be the authority over the entire game state. Thus, Artificial Intelligence, Physics, etc are all perform on the server and only *relavant* state change is sent to clients. Client will only display/play what the Server tells them to. Client-side user input are sent to the server in the form of 'requests'. For example, when a player moves their character forward a request to "move foward" is sent to the server. The characters movement speed, etc are maintained on the server. So once the request is made, the players character position is calculated and the state is changed. The 'real' player is on the server and a 'representation' on the client. This is still on the drawingboard, so no coding, yet. Noel Cower, Cool work on Lotus Particle System. |
| ||
| Sounds interesting. And thanks; Lotus has turned out rather nicely. |
| ||
| Noel, Lotus is very nice. However, I'm concerned about why its doesnt operate well with debug mode. |
| ||
| Frank - probably the request method will produce a lag that is not acceptable for fps controls. expect to get a ping*2 lag, that could be up to 500 Millisecs, depending on connection quality, number of gateways and distance. |
| ||
| Frank: This 'bug' seems to only occur when render tweening is used. Quite frankly, it's got me stumped and I'm actually thinking it could be Blitz's fault. It also appears at random, sometimes it works just fine in debug and other times it doesn't. Could it be Blitz is hitting a bottleneck (or a long machine pause?) and trying to get back up to speed (because of render tweening?)? If you have any information on whether or not Blitz tends to do this at times (with or without render tweening), do share. |
| ||
| jfk, Lag is a concern. Approximation techniques (Cubic Spline Interpolation, etc) will have to be employed. I'm researching other techniques as well. Noel, I have not used tweening often, perhaps, it is a Blitz bug. Either way Lotus is really slick. |
| ||
| Some new updates to ppf2k4.zip. The latest addition is a new scripting system. Note: that I have identified a Float/Integer conversion bug with using the scripting system on different systems. Please advise if you have trouble running the demo. Looking for a better way to distribute updates. A better distribution control system. |
| ||
| What for is this scripting system? Can you explain this a little closer? |
| ||
| jfk, The scripting system can be used similar to the Quake Console or Unreal script. Ultimately, one can script game entities without recompiling the engine, ideal for 'modding'. The feature was highly requested in the initial Project PLASMA and I really worked hard to develop the code. I took this opportunity to ressurect the code. It is not perfected: 1) There is a major float/integer bug (as it stickly works with floats) - No string support, 2) the syntax is very strict and limited, 3) little documentation. But, with some fine tuning, it could prove to be very useful. The scripting system is based on Mark Sibly's Compiler Code and my action system. In which it can handle expressions, arguments, and command calls. |
| ||
| good you are still working hard on this frank. Seems like interest is picking up again |
| ||
Network Design Model (Subject to change) |
| ||
| That network structure seem to be pretty clever. Keep it up. But why in the world would you use Marks Compiler Example that produces x86 Machine Code? |
| ||
| jfk, After reading several articles on Scripting Sytems it was a good choice. Marks code was an excellent start: 1. Provided Parser for parsing expressions. 2. It generated 'OpCode' which I adapted into my own opcode. 3. It was a compiler written in Blitz by the author of Blitz. I sure learned alot about x86 compilers in the process. |
| ||
| hmm, i might be going to update red bron soon. I was thinking of giving him a 512 x texture and change that overbearing red colour to something more subtle. we are nearly finshed the jester demo, so i will have more free time |
| ||
| How about a bit toned down rusty sort of armor? |
| ||
| Haven't you guys realized by now that Frank is a schizophrenic? |
| ||
| yes, its true:) |
| ||
| Has anyone tried out the wipscript engine demo? |
| ||
| I was thinking of that codeD, good suggestion |
| ||
 Weeee. God I hate that name- "Redbrun". |
| ||
| he he me too. how about little big man or 'musclehead' looks good noel. love the facial hair |
| ||
| RedBrun? I thought the name was 'RedBron' lol. Anyways, good work Noel. |
| ||
| Either way the name sucks ;) Should call him Ulysses or something cool like that. |
| ||
| How about Frank and Noel? |
| ||
| I just know I'm missing the joke there... |
| ||
| how about 'red brian' |
| ||
| I've have been currently working on the Indentify by Color Uniqueness (ICU) VIS Multi-Agent Processor. This is a tool that generates occlusion data by reading pixel colors in the BackBuffer equal to a submesh index number. To make a long story short, the process is a fairly slow. Thus, the primary feature of this tool will be the ability to divide the task of processing VIS data amongst 64 Networked PC Agents. In developing this tool I will be working with network code which has been a concern and challenge. Eventually, I will be re-engineering the core for network support. I basically have to split the rendering/sound from state management and AI. I'm shooting for a persistent server design in which the server maintains game state and client is a represetation. Lots of work? It is! However, a modular design and code wizards make life easier:) |
| ||
| Very good idea to let 64 machine do the job together. BTW. check out TeraBits mods to the ICU algo, if I remember right he used to make it run 20 times faster or so. It was in some thread about VIS occlusion where he told me how to make it real fast. I guess it had something to do with the fact that access to the backbuffer is much slower than - some other buffer :) which I don't recall atm. Probably an imagebuffer, or a vram-persistant texturebuffer? |
| ||
| I think it was a system mem buffer -- copy the data from vram to ram all at once, THEN mess with it. @Frank: how fine a grain are you scanning -- I'm doing 20-30 samples a minute at 640x480 without any special optimiation. With the OR'ing of adjacent cell data, I would think you could stay fairly coarse without losing that much. If you would like -- I can poke at the network code for you. Shouldnt be difficult to have a master assign coords to slaves, and the slave do the full 360 scan and return a visibility set. Are you streaming the models across the link or using a shared file system ?? |
| ||
| The name should be changed to 'mr piggledey pop' |
| ||
| Frank, this was the ICU optimation: (Lee): In this case, looking at what was taking the time, I set up multiple cameras looking around in four directions. You can then set their viewports at different on screen positions. That way you have one renderworld with four faces. (you can get a better verticle field of view with a lower camerazoom which eliminates much of the look up and down) It was also taking a long time to lock and unlock the buffer, so having to do it less often by having 4 in 1 renders sped thing up a bit. Locking and reading the backbuffer/frontbuffer seems to be very time consuming, so I copyrected the composite four faces to a created texture which has the +256 flag to lock it in VRAM. From that created texture reading is much faster (really much faster). But it would be better still with locked pixel stuff. My plan ultimately would be to render two positions in one frame by using up the remainder of the texture space in a 1024x1024 frame with another camera set. That would lower the overhead on the copyrect to about half. So about 9 seconds would be about right. I could get it down to between 5-7 secs if I could render directly to a texture! --------- |
| ||
| Frank: how fine a grain are you scanning -- I'm 60 ICU scan/min with the following optimizations: 300x200 4 Cameras Read every other pixel Render to backbuffer only (no flip) I can poke at the network code for you. Shouldnt be difficult to have a master assign coords to slaves, and the slave do the full 360 scan and return a visibility set. Are you streaming the models across the link or using a shared file system?? I'm pretty far into the network code and it will function similar to the way you describe. The current design is a persistent Server which 'Agents' connect to receive 'task'. 'task' are map files stored in the Server's 'task' folder. The folder acts as a queue for maps until they have been processed. The Server will transfer the map file to agents. Once the agent receives the file it immediately begins processing. Once processing is complete the Agent sends the VIS file back to the Server. The Server Assembles the multiple VIS files into one making it available for download.Folks upload their maps via the Client. Thus, their PC can provide an available Agent for processing. I reckon I'll have to set time limits for file storage and auto deletion. |
| ||
| Ahhhh as a remote service -- interesting idea :) I want to steal your code and adapt it to my setup when you are done :) I sounds like you are doing just a single mesh at a time, where as I want to process terrain and the buildings on it, which means streaming multiple meshes to the agent. Not scanning within the buildings, but testing wether or not the buildings are visible at all, if the current scan location is within the bounding box of a dropped prop, that prop gets alpha'd out for that scan. (now that I think about it, that could also apply within buildings) |
| ||
| I want to steal your code and adapt it to my setup when you are done :) Actually, you can download the Work in Progress. Read the PVP.html I sounds like you are doing just a single mesh at a time, where as I want to process terrain and the buildings on it, which means streaming multiple meshes to the agent. It does depend on the map. One map could have terrain and the buildings on it which is where the benefit of multi-agent processing really stands. However if these objects are separate then you will process them one at a time anyhow. I may also increase the Agent support. The server is only connected to an agent when file transfer is necessary, server performance should be reasonable. I'm also considering using a Compression/Decompression for file transfer. |
| ||
| How's it coming along? |
| ||
 |
| ||
 My wit exceeds my ability to reason. |
| ||
| That would have been funnier if there were two Plasma stones next to each other. ;] |
| ||
| Don't be so harsh. Maybe Frank is only on the bahamas for 2 weeks or something. |
| ||
| That would have been funnier if there were two Plasma stones next to each other. ;] Too right. Don't be so harsh. Sugar-coating what I say isn't exactly something I enjoy doing. |
| ||
| Yeah, but while my nurse only slaps with the latex gloves (something some people may like), you already make it a point with no return. |
| ||
| (something some people may like) Nice of you to add that 0_o you already make it a point with no return Project Plasma was a point of no return come the start. |
| ||
| You are correct. It's a great idea, but there are probably only about twenty people in the Blitz and DB communities doing anything useful. And half of them are already working for me. |
| ||
| It's been a month since an update, good enough to declare it dead or on hiatus for me. |
| ||
| As far as I see there was absolutely no reaction on the latest update. What do you expect. If I would release a demo and absolutely noone would react I'd probably stop posting worklogs too. The only problem I see is Frank made the whole approach too complex. But halo - I doubt that the half of the as-good-as-pros of the blitz community are working for you. Or is this kept a secret? And then, if 10 people are working for you, it's a shame we didn't see anything, I mean a reference game of your engine or something. If I had 10 people, I already had 40 Levels. |
| ||
| You have no idea. We're building the entire game content, and developing the engine at the same time. Anyways, that project won't be announced or covered on this site. |
| ||
| You have no idea. We're building the entire game content, and developing the engine at the same time. Anyways, that project won't be announced or covered on this site. Shame. Always fun to laugh at floundering projects... And after the bang-up job you did on CShop, I have every faith that you'll follow through with the same level of quality on this game project. Could you please post some updates for us? Even little tidbits would be enough to fuel my mocking contemptuous laughter... Or at the very least, let us know when the project dies so I can know when to begin pointing and snickering. |
| ||
| Well, that's off topic. Anyway, I wonder who are those guys of the blitz community who are working for halo and why they keep this confidently yet. But I have no doubt halo is capable of making a game and leading a team. It makes me kind of sad that he never asked me to join the team, suggesting I am not one of those who ever made something useful, and I also would like to hear something about the progress from time to time since we all used to profit from eachother, I guess even halo used to profit from us from time to time, so we are a kind of a big family, with the usual flamewars between the kids sometimes. Then again I also understand if somebody don't likes to show screenies every other day, but preferes to finish a product before it is annouced. But in fact this wasn't the philosophy we have seen with some tools halo announced - anyway, I wish halo good luck with his game project and I am really looking forward to see something nice. |
| ||
| I wonder who are those guys of the blitz community who are working for halo Best I not mention my experience 'working' for halo. we are a kind of a big family I guess that makes me the older, more mature sibling. (that, for those who don't know a joke when they see one- and when it's through text, I can't blame you-, was a joke) |
| ||
| Best I not mention my experience 'working' for halo. What, I told you what we needed and you never got back to me? Shame. Always fun to laugh at floundering projects... That kind of negativity and the general backwardness of this community (good graphics are undesirable?) are the reason we don't post news about the project. It's a totally unmoderated, unstructured hole in the wall where a few talents can be found. Reminds me of the classic Quake mod community after Quake 3 came out. JFK, I actually really like your stuff, and was kind of thinking of your FPS demos in my top 20. I thought I sent you an email at some point proposing something, but for some reason it didn't work out, or you were busy. Let's chat. Anyways, I'll leave this thread to Plasma now. |
| ||
| What, I told you what we needed and you never got back to me? Actually, you never got back to me, but it already happened so there's no sense in trying to argue over it. |
| ||
| jfk, I like ur demos.I think I told you ;) Off topic, I know. |
| ||
| . (not worth it) |
| ||
| ... |
| ||
| top quality modular FPS Engine I think what you need to be concerned with is making it readily useable by others. Vein is and has been an easily useable engine from the get-go, it only takes a few lines to do the simplest tasks in it. From my short experiences with Plasma, it's a tedious and painful task to do anything. But hey, you can always start over. |
| ||
| Noel, Vein? Please elaborate. Thx |
| ||
| Frank: Vein, my old engine. You complimented its design once or twice in the past, albeit it being slightly dated now as far as Blitz3D's useability (and my ability to make things look awesome) goes. |
| ||
| Never heard of it. Any working demos?(.exes) |
| ||
| I'll take that as a no, no working demos for vein either then. (Just trying to bait you into uploading one...;) ) |
| ||
| Well, since he stopped working on it, I'd say a demo is firmly in the "not likely" bin. |
| ||
| Well considering someone complimented noel edmonds on it's design I'd say it's a safe assumption a demo was released long ago. I was after that. |
| ||
| Otacon: Demo is still 'in the works' (in other words: don't count on it). Although, to be honest, I hadn't noticed your asking for one until now :P My current work just consists of writing a library for C++ that mimics the Blitz3D API (using OpenGL, since I 1. can't stand DirectX and 2. can't use DirectX in Linux without emulating it). Fun stuff. |
| ||
| Update. Or be declared dead. Again. For the hundred-thousandth time. |
| ||
| Mmmm...maybe the project did go a little overboard. Start simple, expound later would be a better approach perhaps than starting an ambitious project from the get go? I'm just throwing that out there. Not, that I'm a better programmer than Frank. Nor, worse but, fps engines aren't quite my forte'. Regards. |
| ||
| Once a project reaches a certain size, it ceases to be fun and becomes work. This is usually the stage when most hobbyist projects die out. When all the high level design and tech is done and the grunt work begins... Plasma may be at that stage and Frank is deciding if he wants to stick it out or not. |
| ||
| I am looking for someone to handle the vehicle system for V-E Day. The project has a strong team with a good history of commitment. |
| ||
| As some of you may be aware I have taken recess to study Game Engine Design with the Torque FPS Game Engine. I've have been learning a great deal from it. For the most part, PPF2K4 current design is very modular and consistent. In fact, I've adopted some techniques used in PPF24K for use in Torque. PPF2K4 will have to be redesigned at the core for optmized server/client architecture. Single player games will also make use of server/client architecture. Essentially all entity control and state will be managed by the server. The client will be responsible for collecting input and Rendering and sound production. I'm really excited bout the new concepts i will be bringing from Torque. Stay Tuned. |
| ||
| My God if your going to do this "PPF2K4 will have to be redesigned at the core for optmized server/client architecture" then we better change the name to Project Plasma Next Century. For a community project to make a "simple" FPS engine and game that people could expand upon you seem intent on making it the most complex project on the planet. When ever anyone suggests making it simpler or even suggests an idea that differs from you vision you seem to disregard it or spout a pile of useless buzzwords and then wonder why no-one else seems to be helping out much. I wish this project would succeed but at present it sounds like "Technology" is taking over from common sense and the goalpost is being moved ever further away. |
| ||
| This is what Frank Taylor does. You should have figured that out by now. |
| ||
| Haven't you guys realized by now that Frank is a schizophrenic? He's taking a mental poll to determine whether to do something the simple way or the hard way. Obviously the majority of the people in his head went for the hard way. Frank: I think you need to drop making this in Blitz3D and use an engine that allows for better control overall. Frankly, I really doubt Blitz3D is going to cut it if you continue with the client-server concept (I think we all know how slow Blitz3D's networking instructions are 'on an average day'). Might as well switch to C# and Managed DirectX/Axiom if you continue this, that way it'd actually stand out and you might get more help from a greater amount of people. |
| ||
| I think you should do it in machine code...actually, you should make your own computer specially designed to run this...and you should start with the wheel. Then you would NEVER have to think about finishing! You need to write out EXACTLY what you want the game to be, and then pursue that wuth the simplest way possible. This is no small task, and I only feel like I am now getting a handle on a real FPS game engine. You should write your game before you worry about making your game modifiable. I write my routines in .bb code, and I might or might not move them to script after I finish. Lastly, I strongly recommend using my "Structures" code for storing all entities, objects, events, etc. It is easily accessible from a DLL or script, it makes it easy to load and save items. Since the structures are just banks, they can reference other structures, different kinds of structures without special variables. |
| ||
| I agree. This project looks like it's being lead by someone who enjoys designing more than coding. Nothing wrong with having that passion, but that's the wrong passion for getting something finished. Start with the simplest solution and generalize from there - IF necessary. Not everything needs to be pluggable. |
| ||
| I started with a vague entity update concept, but once I just went through and listed the entities I wanted, it was much easier. I had projector entities I wanted updated before the render, so I put in an UpdateProjectors() command. It can be intimidating, because you might not know all the entities you want, but you have got to list them and know what they do and when they update. |
| ||
| halo: Do you have a copy of this structures code on hand? If you're handling them through banks then I should like to see this, because it would allow a lot of options that normal types don't. |
| ||
| Structures.bb Classes.bb (make ti whatever you want) |
| ||
| Thanks; just a note: you might want to use <codebox> instead of <code> to minimize the amount of space it takes up on screen. Not a big deal for me, but some people might start complaining. |
| ||
| Halo, I posted a similar reply in another thread asking about the string operations in your Structures/Classes code. (I believe that the reply was you use Purebasic to perform these operations.) Question: Do you have a solution that works in straight .bb code? Is it just too difficult in bb, or too dang easy in Purebasic? Thanks, |
| ||
| Now if only this many people would help me make my game. See below |
| ||
| Is that really the kind of 'help' you want? |
| ||
| I've said this before and I'll say it again...just because!! This project shouldv'e just started with a simple model. While, it's admirable to say we're going to implement all this 'stuff' it would have been far better to first release a simplified version with good commenting that nearly everyone could understand and get into. Perhaps, it would be better to let advanced features be up to the user but, also to have a structure in place that would let the user easily add his/her own features. Not, that I could do better. FPS is not exactly my genre of expertise when it comes to coding. I'm just...you know...saying man. |
| ||
| . |
| ||
| PROJECT PLASMA 2004 WILL NEVER DIE!!! I've learned an enormous amount from working with a Commercial 3D/Network Engine. I'm going to do my best to bring what I've learned to BlitzBasic3D's PPF2K4!!!!! I will share with you applications of 3D Animation, GUIs, Network, Scripting Systems, and much, much. You will not find this information anywhere on this site. |
| ||
| PROJECT PLASMA 2004 WILL NEVER DIE You should never say never in the context of software development. That said, I expect you have just jinxed yourself. Now here's a suggestion: rewrite the entire engine. |
| ||
| >>PROJECT PLASMA 2004 WILL NEVER DIE!!! << That's ok. Just make sure it's finished one day. |
| ||
| That's ok. Just make sure it's finished one day. His son's son's son's son's son will finish it. |
| ||
| @Noel - hehe. Rebuild the engine. Hmm. Not a bad idea. |
| ||
| This is a lesson i learned a hard way myself |
| ||
| @aab - what lesson? |
| ||
| THE LESSON! Jeez... So yeah, what lesson? |
| ||
| . |
| ||
| Have fun trying to decipher my mind bogglingly strange coding style. Which changes between projects. |
| ||
| Dear Moderaters, Please unstick this forum thread. Sincere Thanks, Frank Taylor |
   |