Zervoxe

Members
  • Content count

    54
  • Joined

  • Last visited

Community Reputation

1263 Excellent

About Zervoxe

  • Rank
    Member
  1. What engines do you use, and why

    I do not think he ruled out Cryengine,Unreal and Unity, he simply said that he wasn't asking from a AAA perspective. which tend to use these engines but does not exclude them from being mentioned) Also from what I gathered he wasn't asking for an engine to use, he just wants to know what people are using and why/what they find attractive with them.
  2. He is still doing updates for all platforms he supports, thing is now that the platform support have matured it isn't as much hazzle for him anymore, latest updates are actually quite noticable for both desktop platform and mobiles. dated? you mean the editor or the visuals? as has been the case for a while EE lacks somewhat in the shader department still(when it comes to visuals) the extended source pricing back then was quite expensive compared to the new licensing, so yeah that is no longer an issue(although the new one is recurring, it is paid once a year) but still compared to the 1.0 source access cost and 2.0 extended source access costs I'd say it is more than ok. Let's see 2013..that was initial EE2.0 if I remember correctly? if so yes there has been changes around the editor. the pricing model is available on the website.(full source access is available as a subscription as well as the non source) I do not consider the prices to be too steep(it's possible to download the editor and run it for free, although it is a bit limited(not in features but in limitations in things you can have, max object count in your project), a bit too limited according to some people, although I would say it should be enough to test alot of things still).
  3. I am a fellow user from way back, Still using it personally, I love it due to its stability. the latest updates has had quite some optimization passes. Couldn't tell you much directly about the editor as I tend to limit my usage of it quite alot(my projects are mostly based on my own handling so I do not mess around with it) mostly I just do asset import through the editor and thats it.
  4. you use in-game units to calculate bulletspread, using screen would mean you are firing from your eyes instead of the gun. crosshair is just a representation of where the player is aiming, where size of crosshair doesn't affect the spread, it just shows/scales from your accuracy based on values from the gun's current values there is tons of tutorials regarding this matter and I think even if it is a different language and engine you should be able to learn from  them. :)
  5. http://support.lenovo.com/no/en/products/Laptops-and-netbooks/Flex-Series/Flex-10-Notebook-Lenovo?tabName=Downloads&linkTrack=Mast:SubNav:Support:Drivers%20and%20Software|Drivers%20and%20Software&beta=false I see there are Bios updates available(try specifically the 64bit one)(strictly speaking the Bios lacks something).   https://forums.lenovo.com/t5/forums/v3_1/forumtopicpage/board-id/Special_Interest_Linux/thread-id/6206/page/4
  6. No such thing as 32bit mobo. Depending on the install medium this might have something to do with it, lack of proper drivers.
  7. https://www.community.arm.com/graphics/b/blog/posts/dynamic-soft-shadows-based-on-local-cubemap https://www.assetstore.unity3d.com/en/#!/content/61640   I am curious if this is somewhat related.
  8. Worlds within worlds!

    I assume you know there is quite a bit of a difference between portals like in the games like Portal and Prey, and Portal Rendering system which is used for a quite different purpose? This does not exclude one from the other to be combined.(or as you rather grossly(I use grossly because I can't think of any scene management system which doesn't allow for this to happen) described it worlds within worlds).
  9. Worlds within worlds!

    So, first you made the only comparison on how you clipped the scenery according to the portal, now you require it to prove light and shadow as well? you are aware it was impossible for them to develop something which was flat out impossible for hardware to calculate at the time as it was not hardware accelerated(eg it did not benefit from having an insanely powerful GPU?)
  10. Worlds within worlds!

    the first portal rendering usage in games, didn't even have dared to try using render to texture, that means even something like mirrors was impossible had it not been for the original portal rendering technique used back then. Duke Nukem 3D from 1996 used it. then you also have Marathon from 1994.
  11. Worlds within worlds!

    Then why not just post this as a personal journal post about you implementing portal rendering? as I see absolutely nothing groundbreaking not already done in lots of other engines or titles.   the reason I have to say its not groundbreaking, is because you seem to think you invented something which looks and acts exactly like a traditional portal rendering engine does. :mellow: We already know it is.  :blink:
  12. Worlds within worlds!

    you mean like how portals is supposed to work?
  13. Worlds within worlds!

    Vague topic title made sound important with "!", vague description of a system, mentions an idea and a non described acronym. This makes it very hard to even wonder what this topic is about. :mellow:
  14. This of course is all my subjective opinions, so feel free to disregard it if you will. "I'm not so much experienced programmer on gaming but just know Python well and some C# and JS knowledge. " Just because you know a programming language does not mean you know programming, that being said I do not know your how much experience in actual programming you have.   "please don't advice me game engines'  -Godot- game developing video tutorials what are not theoretical to teach you general logic on game programming most of them show how to clone existing game or teach you how to clone video instructor's game"   Why wouldn't you follow these tutorials? a lot of people would actually suggest you learn by making your own clone of chess,tic tac toe, snakes, tetris or similar games to build up the basic knowledge needed to continue on.   "-don't give me the fish but teach me to fish -" why not have both? Developing a clone is not easy, is it easier as you know what to copy, probably, but you learn ALOT of an engine by seeing the process. after seeing actually code, you can look up their functions and learn what they do and more importantly, why they did it.   It isn't only the code specifically you should look at, but the functions they use, when,how and why. Very important things to learn when learning an engine.(and you will probably trip over and pick up some bad habits and look at your code even possible the next day and facepalm yourself for writing such code)   "Game Engines like Unity, Unreal, Duality, Löve and most last Godot. I'm sure now that gonna continue with Godot and not to change it." This is what most people trying to learn game development do wrong, can't learn one engine, next!, can't learn that, next! and so on. That cycle will continue until you learn to buckle down and try see the similarities instead of the differences of each engine. afterall many engines does things in very similar manners even if their languages differ. Learn by looking at examples of scripts, tiny sample games, alter them, play with them,"taste" them, read the documentation of the functions/classes so that you have a better grasp of all their functions/methods.   I would suggest like Kirlim's suggestion reading about design patterns and programming paradigms.
  15. Variadics

    I am curious, has there been any update regarding this?   I am referring to this some months ago, it would be a well appreciated addition.  http://www.gamedev.net/topic/680460-delayed-calls/