Jump to content

marauder2k9

Members
  • Posts

    433
  • Joined

  • Last visited

Everything posted by marauder2k9

  1. we can make it at a time that suits most people like this isn't set in stone yet lol
  2. that is the idea use the next version that is precompiled release of preview 4.0, the other thing this one just for the moment is going to be just T3D later on there will be a T2D one as well just because i think for testing purposes both engines have very different needs
  3. so to answer all of this 48 hours was just something stupid to put into one of the answers the rules are not set yet it could be a weekend thing could be a week long thing don't take the 2 days thing so literally you'll give yourself a heart attack anyone that thinks the point of a game jam is to create a game in 2 days is laughably stupid. Most of the time it is usually to make a single level or even just a concept and on the face of it most of the time it is to not only test yourself but to test the technology. Torque 4.0 is nearing closer and closer and therefore it needs testing and put through as much stress as possible to show potential flaws and or features that need to be added for 4.1. "Game jams usually produce primitive garbage games" some of the games that have came out of jams have better gameplay and look better than some of the shit that has took years of development. "because you cannot control how much time someone really spend on it" this is why these discussions happen, az jeff and i are talking about possible themes that would be announced when the jam starts not months in advance. Not only that but how many game jams are just about artwork? Practically none tbh because a game can look as nice as anything but if it doesn't have good gameplay it would be shit and wouldn't win. Visuals most of the time aren't even marked or counted let alone praised. If you don't like the idea of a game jam, you don't need to take part its that simple. Everyone else that is interested in it can and hopefully will. Its very easy with the new engine to get something up and running rather quickly and there will be modules and assets in place to help people too. Hell one of the ideas might be to do with using certain assets only so that takes your art out of the question.
  4. funnily enough i was thinking something similar along these lines, there is a lot of art out there that was released for torque and is still free and open source that we could pack into one download
  5. +1 Not to mention the urgency leads to some good ideas that could even end up in another project. Its like brainstorming you fire out ideas so quick your brain just makes it second nature and you stumble onto ideas you never thought you could come up with.
  6. @Scott Burns damn a wild scott appeared good see some members of the old guard
  7. this could be set to take place anytime yano pick a weekend or something, most of the game jams ive seen are usually only a single level that showcases gameplay and most of the time its simple gameplay too make this sphere run away from this deadly cube kinda stuff lol
  8. can compete just can't win lol i want to take part as well even though i can't win because ill be offering up the prize, ill just be taking part as a way to train because its what game jams are good for exercise the mind a bit test the engine etc
  9. kinda what a game jam is all about lol
  10. Answer the poll and if its popular enough we may host a game jam, and if its really popular it might become a usual thing. EDIT: It should be noted that for anyone sitting on the fence on this, the rules for this are not set yet any input you want to give please share and it might just become a part of the game jam anything at all from timeframe to prize that would be acceptable all feedback is not only welcome but required.
  11. ANNOUNCEMENT Link: https://github.com/TorqueGameEngines/Torque2D/releases/tag/v3.5 A brand new version of Torque 2D is out bringing us up to 3.5 This new version brings with it: Updates to the Box2D Physics Library with the LiquidFun version to allow for Physics Particles. Particles can now be given a target to move the particles towards that location. Simple paths and path objects can now be created. New Light objects can now be created. This update also includes a few bug fixes including a bug fixing the custom cursor for MacOS and Windows.
  12. Rules/Guidelines are right here https://forums.torque3d.org/viewtopic.php?f=15&t=1593
  13. You are right, but i will say my idea was not to prove to be unreals contemporary more along the lines of just showing that it can be done in torque
  14. nobody has made a demo because there is nothing to make a demo of. there hasnt been any major updates to the engine since 3.1 with 4.0 being the next major update there would be demos made for that to be sure. But 4.0 isnt released yet and is a bit unstable at times so no one wants to make a demo for it yet apart from maybe the steering committee, but they are making simple things to show off certain features no fully fledged demo yet but there will be. I'm merely suggesting ideas that i wouldn't mind helping on but i wont be able to do it alone. A demo similar to that wouldnt be too hard or take too long to make when you think about it. Ive often been thinking a viking style demo would be amazing for torque white cliffs grassy fields a temple in the mountain etc
  15. engine demos are sometimes freely available to test and play around with, the assets might be able to be converted over to torque, but if its all dynamically created i don't know even where to begin to take it into torque. And from their website unreal 5 wont be out until 2021, waiting that long sounds boring lol I wonder if we could work together to design a similar tech demo. It will take time but imagine an open source engine being able to re-create the unreal demo before it is released to the public. Could get a lot of attention but again it would have to look the part. With the work JeffR and the steering committee is doing it is very possible to make it look as realistic if not more realistic but it all falls on the artwork created for it. Does anyone here have Zbrush? Torque4.0 pre release has directx12 if im not mistaken? Because torque is open source we could create a demo similar for non profit educational means without causing any problems. And release it for people to play around with.
  16. But the demo is a controlled situation... The thing is that whole scene screams to me that as what Bloodknight had said its just flexing and boasting. And as Duion said textures at 8k textures and certain polygons that are only a pixel size, really isnt useful to an artist or a developer, this tech demo i think was for end users people who are going to be playing games. I have no doubt this is probably running on a PS5 and in real time, but it is a completely controlled scene, it would be interesting to know the techniques that were used to make the rest of the scene, they only talk about the opening scene as being dynamic, but the rest of it im not too sure about. this is what is going to really bake your noodle, the ability to run a billion tris has always been there. You ever tried to push torque to its limit? It can render scenes like that and it wont bust the engine it just doesnt have the dynamic model and textures in it yet as far as i know? But it can do it! push a 20 million polygon model into torque and you will see what i mean it will run just as smooth as that does but again it just is not practical for anyone let alone end users. Torque can also take 8k textures, its nothing new. Again sure if you want to develop games for people with the latest hardware top of the end stuff then sure, but as we all know you will only be getting into what 10% of the market? Maybe even less. Of course you could develop solely for the consoles too but then again they have to have the latest playstation or latest xbox to run this smoothly without LOD's and other methods. Also dynamic LOD's and dynamic tessellation is also old tech, but there is a reason why artists choose to do it manually. More control over the final outcome. I remember a directx 12 demo about dynamic tessellation but artists quickly realized that alot of the polygons being added while useful for displacement maps they weren't really adding any extra detail that couldn't be done with LODs that are controllable.
  17. Yeah while this is impressive its really only useful for certain set pieces such as whats shown in the video. I don't think this would work too well for something more fast paced. Also if you look closely you can see a lot of pop in on the statues when they are in shadow. If this is basing polygon counts on ray traced lighting which it very well may be, anything in shadow is going to look pretty bad if you don't use conventional methods to model and texture the geometry
  18. Exponential Falloff implementation is put here: https://forums.torque3d.org/viewtopic.php?f=23&t=1423 The reverb was added also in a pull request that i think is in the development branch of the engine now so you can put different effect types into environment triggers that will produce different types of reverb to emulate environment types in all sounds being played.
  19. Latest Update Thought i would write a little bit giving an update on how things are going. For the last month i have been fixing and updating one of my releases and working on a couple of new ones. The editor has made this a lot quicker but i have found quite a few problems that i have been fixing along the way but i have remained focused on finishing my own projects for this reason i have been a little quiet here and i apologize for that. The good thing that came from this is i have been updating and fixing problems a long the way things that i found easier to work with throughout developing my own apps and games. The new features that will be added as soon as i finish these products and get them out are as follows: New Main window - now there is a scene list that has every object in the scene added to it, this includes joints and force controllers with the options for hiding them and locking them. At first i thought this may take up too much screen real estate but it became more and more necessary throughout development to be able to select objects etc. Move to Object - Now with the scene list you can select objects and modify their settings(fairly standard stuff) but now also you can move the camera to that object. Camera Layer - A few changes have been made to the camera but one thing i found quite useful is the ability to choose which layer to make visible. This is only used in the editor any output from the editor will render all layers. Camera Link - Now you can link the camera to an object and set the link properties. These settings are only visible when the scene is playing as the camera object in the scene becomes the settings for the scene window to help visualize the settings and how a game might play out. Triggers Added - Now triggers have been added as a visual but only a visual unfortunately. The scripting for how these triggers work is being confined to simple behaviors. So for example you would have a change level behavior for a trigger that will let you choose which scene to switch to when the trigger has been entered. Now these triggers are only going to work when the level is exported for obvious reasons. Not good when testing a scene and it changes when your character enters a trigger.... not fun... it happened more than once lol Extra Menus - Now there are extra menus for handling how a module operates and how a scene operates. For example you can now press F2 to bring up scene specific settings such as gravity batch render settings etc and press F1 for module settings that so far only really has a setting for choosing what the default scene is. Particle Asset - this was a difficult one but now creating particle assets now takes you to a completely empty scene with the same camera settings as the scene you are working on so scaling can work. This seemed more and more necessary the more and more i worked on a level as a level became more populated. Scene Object menu - Now this one was difficult to come to terms with. As you may know if you went through the source code of the EditorToy every object was separated out because each object required different settings but they all shared certain settings. For example everything a sprite has access to a scroller has access to they just have specific settings for scrolling the image. So now every object specific menu has been moved to one file. A check is made when an object is selected to see which type of object is selected and a new menu item loads for the specific settings for that object so for example every setting that is available for a sprite is available for the scroller but now the scroller has a specific scrolling section for the scroll settings. This works faster for the editor. The other file that will need work soon is the ParticleAsset creation. While moving it off to a separate window it still has about 100 calls to completely similar settings that should be able to be simplified such as all the data keys. While they work well at the moment you just have to look at the size of the file for the particle asset. Thats a lot of code to call for one file and while i haven't experienced any slow down working on a particle asset it is an accident just waiting to happen. So i am planning on re-working the particle asset gui and data keys to be procedural. Really you don't need 4 keys being handled if you only have 2 keys with settings in them. A bunch of other fixes have been made in the background and i still haven't really figured out a good way to modify assets that have already been made. But the answers are being worked on and may become a reality as the longer you work on a project the more and more you need to modify assets. While it is quick and easy to just add a new asset for images and sounds, working with animations is a little trickier the more you play your game you notice this could use an extra frame here or a frame less there and having to create a brand new asset and then go through each object and change it to the new animation asset is a little tedious. Big things are on the horizon. Time wise i will be hoping to get all these changes up before the End of June. I am still dedicating most of my time to finishing my current projects. These changes were worked on in the background. They may have some serious problems that i haven't noticed but they seem to be a lot better for the time being.
  20. You are such amateurs, always use DXT1 if possible, if you cannot because alpha channel, delete alpha channel, since those textures are not supposed to have alpha, but even DXT1 can have alpha, just no gradients in it. DXT1 gives best performance, since it is half the size of DXT3 or 5. And someone should go to the Flightgear developers and punish them for their development style crimes, but hey wait a minute, I just realized why they may do it that way, the reason is if you have an atlas texture with no textures right or left to it, you can tile the texture horizontally using the atlas texture without creating new polygons. So this may be the reason for that weird format, but I see they also have textures next to each other, which breaks this system again, so no idea, if they are genius or just stupid. The textures are also too small, should be at least 512 pixels or even 1024, think about upwards compatibility, which open source developers usually never care about, but a professional developers usually always keeps the high res versions. DXT1 is smaller for a reason, due to the finer details in the texture he posted he should use DXT3 if you look at this image, the pic on the left is the original image the one on the right is after DXT1 compression. The finer changes in color are completely removed under the compression. You have too many details in those textures that are close together such as the roof tiles. if you were to have them as DXT1 these details would be lost. This happens because DXT1 is only 4 bpp whereas DXT3 is 8 bpp EDIT: Also just on that point about the Flightgear developers. They probably modeled whole cityscapes in one file with simple geometry plus, being a flight sim they would have probably thought most of your time would be spent yano flying! as far away from any of those textures as possible. Smaller textures actually look better from further distances. That's actually why mipmaps are used in a lot of games, its not to save on resources as using mipmaps actually use more resources because the engine is loading more textures than if you were to just use the default texture, but if you already start off with the smaller texture u don't really need them if these textures are specifically meant to be viewed from a distance.
  21. blessed is the DDS and its dxt compression lol The thing is DDS format actually goes direct to gpu, as far as i know png and jpeg and a load of other formats have to go through some form of progressive compression before being read into memory on a gpu so with them as dds you just saved your gpu from having to work another step harder :D
  22. well there are some black areas on that texture map so im guessing it has alpha? but it doesnt seem to have any fading alpha so no banding should occur from DXT3
  23. i would guess that flight gears engine doesnt do mipmapping or at least is selective mip mapping, import that texture as a dds file with no mip maps, you shouldnt get any errors and it would have a smaller footprint on vram because of both that and the dxt3 compression
×
×
  • Create New...