Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 07:22:32 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)General programming discussion
Pages: 1 ... 12 13 [14] 15 16
Print
Author Topic: General programming discussion  (Read 28925 times)
ProgramGamer
Administrator
Level 10
******


aka Mireille


View Profile
« Reply #260 on: March 31, 2018, 09:15:39 AM »

If you double click on an instance in the room editor, you'll be able to rename that particular instance to a more sensible name, and then use that name in either a creation code script or a variable in another instance.
Logged

DireLogomachist
Level 4
****



View Profile
« Reply #261 on: March 31, 2018, 01:57:26 PM »

Ah that makes more sense. Thanks!
Logged


Living and dying by Hanlon's Razor
useurname123
Level 0
*


View Profile
« Reply #262 on: April 08, 2018, 06:03:57 PM »

not sure where to ask but is UE4 good for open-world sandbox city-building game?
Logged
Ordnas
Level 10
*****



View Profile WWW
« Reply #263 on: April 10, 2018, 12:59:55 AM »

UE4 is the most used third-party game engine (also  Unity) for its rendering and its pipeline tools.

Unreal is very versatile on different genres, no more Fps centric like UE3. The open world it is very achievable and very easy to implement, using different layers (which are maps) on top of a root map called the Persistent, and bounding boxes that loads and unloads in a asyncronus way different maps, to give the impression of a single gigantic map.

About the city building it is not complicated also, the difficult part is the GUI which UE4 handles very well with the so called Widgets.
Logged

Games:

JWki
Level 4
****


View Profile
« Reply #264 on: April 10, 2018, 06:13:40 AM »

If you have to ask if a certain tool is a good choice for something, you probably shouldn't be attempting that thing in a professional manner yet - and if it's for a hobby or personal project, any commercial engine will probably be able to satisfy your needs
Logged
useurname123
Level 0
*


View Profile
« Reply #265 on: April 11, 2018, 04:45:57 AM »

If you have to ask if a certain tool is a good choice for something, you probably shouldn't be attempting that thing in a professional manner yet - and if it's for a hobby or personal project, any commercial engine will probably be able to satisfy your needs
 
 
That's wrong, asking is the first step in learning. That's like saying "don't ask how to use a hammer if have never handled it" 
 
I use UE4 because its the engine I chose to learn, its all in the process of learning.
Logged
JWki
Level 4
****


View Profile
« Reply #266 on: April 11, 2018, 05:21:32 AM »

If you have to ask if a certain tool is a good choice for something, you probably shouldn't be attempting that thing in a professional manner yet - and if it's for a hobby or personal project, any commercial engine will probably be able to satisfy your needs
 
  
That's wrong, asking is the first step in learning. That's like saying "don't ask how to use a hammer if have never handled it"  
  
I use UE4 because its the engine I chose to learn, its all in the process of learning.

I think you misunderstood what I said.
I'm not saying don't ask stuff, by any means, sorry if that came across like that. I'm saying if you can't estimate if a certain tool is right for a project, you're not ready for that project _in_a_professional_context_ - so if you're a small indie looking to make something commercial, you should rethink your scope.
However, in a hobbyist / learning context, it will not matter too much what engine you use - and if you specifically chose to learn UE4 then your question is already answered anyways.
So basically my point is while asking stuff is as you say the first step in learning, there's not much to learn from your specific question here - either you are in a situation where you should know the answer or rethink your goals, or, what I assume is your situation given your reply, you're in a situation where the answer does not really matter much.

Or to correct your analogy, I'm not saying "don't ask how to use a hammer if you have never handled it", I'm saying "if you're building a house to get money, you should know what to use a hammer for, if you're doing it to learn how to build a house, it doesn't matter too much if you're using a hammer or your head to get the nails in".
Logged
LittleTwig
Level 0
**


View Profile
« Reply #267 on: April 12, 2018, 12:46:31 AM »

I disagree with that.

Game engines are not omnipotent. It's better to ask if an engine is "good" for something, rather than spending
a huge amount of time to learn the engine, just to notice that there are deal-breaking issues which make the initial goal unreachable.

For example, you can't have deferred rendering with an orthographic camera in Unity, so you are out  of luc kif your game has tons of dynamic light sources. Another thing is the lack of realtime input in UR/UE, so you can't really make a decent fighting game without a huge amount of headache(involving multiple threads and syncing).
Logged
oahda
Level 10
*****



View Profile
« Reply #268 on: April 12, 2018, 07:45:28 AM »

On that note, here's a thread that made the rounds the other day about potentially deal-breaking limitations of Unity for a larger project, in case it helps: https://www.reddit.com/r/gamedev/comments/8b5guy/a_warning_to_professionals_considering_unity_for/
Logged

Ordnas
Level 10
*****



View Profile WWW
« Reply #269 on: April 13, 2018, 12:54:37 AM »

Thanks Prinsessa, it is a really interesting link. The problems mentiond on that thread were quite serious if compared to Unreal Engine 4. At work I am using UE4, while my indie projects are made in Unity, mainly because UE4 needs a really high-end PC to work without slowdowns on a very large codebase project.
Logged

Games:

JWki
Level 4
****


View Profile
« Reply #270 on: April 13, 2018, 07:09:59 AM »

I disagree with that.

Game engines are not omnipotent. It's better to ask if an engine is "good" for something, rather than spending
a huge amount of time to learn the engine, just to notice that there are deal-breaking issues which make the initial goal unreachable.

For example, you can't have deferred rendering with an orthographic camera in Unity, so you are out  of luc kif your game has tons of dynamic light sources. Another thing is the lack of realtime input in UR/UE, so you can't really make a decent fighting game without a huge amount of headache(involving multiple threads and syncing).


No game engines are not omnipotent, but I'd argue that for a hobby or learning project unless you have *very* specific requirements, and in that case I repeat you *should know what those are and be able to ask more specific questions*, it will not matter because you're unlikely to exhaust the limits of whatever given engine.

However I wasn't trying to argue your right to ask whatever questions you want to ask, I simply wanted to mention a different perspective on questions like the one you asked. So sorry if that was offensive to you or anything.
Logged
LittleTwig
Level 0
**


View Profile
« Reply #271 on: April 14, 2018, 03:36:06 AM »

I didn't ask anything. I'm just a random bloke Well, hello there!.
Logged
JWki
Level 4
****


View Profile
« Reply #272 on: April 15, 2018, 07:10:52 AM »

I didn't ask anything. I'm just a random bloke Well, hello there!.


Oh right I didn't even notice sorry
Logged
Oats
Level 1
*


High starch content.


View Profile
« Reply #273 on: April 27, 2018, 03:36:11 AM »

Has anyone here ever used Rust? I'm 5 or so hours into writing along to its manual https://doc.rust-lang.org/book/second-edition/ch06-01-defining-an-enum.html, and so far I don't honestly see a reason to ever use any other systems programming language. It has far better type safety and memory management then java (coming from a 6+ years java programmer), with no runtime and the speed of c++. But unlike c/c++ it's impossible to have double frees or to access freed memory. It also seems to have the same complete thread safety of functional languages while still allowing mutable data. Plus on a personal note I really like it's syntax, it has the feel of a dynamic language even though it's statically typed.

That being said I've yet to program anything outside the guide, yet alone a game with it, so I was wandering if there was some game breaker I've yet to encounter, or any reason why it's unsuitable for specific uses.

TLDR; rust seems unreasonably good at everything.
Logged

eh
qMopey
Level 6
*


View Profile WWW
« Reply #274 on: April 27, 2018, 10:58:57 AM »

Just to share another perspective, the idea that it’s impossible to double free is a total turn off for me. When I write C or C++ my problem is never “how to avoid double free”. In general I’ve never had a problem with safety of things, so why would linguistics solve a non-problem for me? Personally I’d love to see something that takes C, adds function overloading and operator overloading, default function parameters, and base offset pointers. Base offset pointers are a great example of how language designers routinely ignore useful and practical features in favor of chasing misguided and ambiguous ideals.
Logged
Oats
Level 1
*


High starch content.


View Profile
« Reply #275 on: April 27, 2018, 09:21:35 PM »

I've never used c or c++ with any seriousness, so I can't compare them with Rust. I do see that most of Rust's features could be emulated entirely in other languages, without the need to enforce them in the compiler. But I think the point of Rust is to push people towards good practice, and to write thread safe code without thinking about it. All said and done I probably don't have enough experience outside of java to talk about these things.
From my perspective manual memory management sounds like an unnecessary headache, and while I'm sure you learn how to quickly handle memory safely overtime, having memory automatically deallocated when a value goes out of scope sounds very natural too me. Achieving this without introducing the disadvantages of a GC seems very neat.
Logged

eh
qMopey
Level 6
*


View Profile WWW
« Reply #276 on: April 28, 2018, 06:25:56 PM »

I would definitely agree that running a little bit of code when a scope ends, is definitely a good idea. Though I do not like the more modern RAII idea really at all (just a disclaimer). It's useful to group load/unload, init/shutdown function calls together line by line, but have one run at the end of the scope.
Logged
Oats
Level 1
*


High starch content.


View Profile
« Reply #277 on: April 28, 2018, 09:50:02 PM »

Could you elaborate? i don't know what you mean by "have one run by end of scope"?
Logged

eh
CodeLobe
Level 0
***


Decide to Act Sensibly


View Profile WWW
« Reply #278 on: April 29, 2018, 07:15:24 PM »

Personally I’d love to see something that takes C, adds function overloading and operator overloading, default function parameters, and base offset pointers. Base offset pointers are a great example of how language designers routinely ignore useful and practical features in favor of chasing misguided and ambiguous ideals.

I agree.  I code a lot in Assembly languages and I just love being able to construct OOP or stacks of state machines, whatever paradigm, simply by being able to apply base + offset to literally anything.  When I climb out of embedded space and have to think around problems in higher level language constructs, fitting the problem into the chosen paradigm just seems like such a waste of brain cycles when I know how to do it in OP codes.  I like C because it's basically a preprocessor for assembly language.  C language constructs match the hardware features nearly 1:1 because the hardware and C grew up together (back in the day, programmers would ask for new instructions that made programs go faster, eg: ENTER / LEAVE for calling functions & returning from a stack frame.

Such features actually limits language and program design, despite the academics willfully denying such.  Languages are a product of their hardware / environment (even among humans & animals).  You can make a computer language do cool & different things but it will be slower because the hardware itself is made to run the C paradigm of functions better.  For example: What if you put your stack frames on the heap instead of the stack?  Suddenly you have "closures" and your language runs like crap because CPUs are optimized for function vars to be on a small local stack, not garbage collected in a dedicated cache pool.

If you try to replace C, you will end up implementing language features that closely match the hardware designs, and wind up with another C that has a different looking syntax (I've done it and learned the hard way) -- Otherwise, your language won't have some system level feature that an OS dev needs to make OSs work on today's hardware.  If you try to create hardware that does things better then it won't get adoption since it will have to compete with other chipsets that run C code faster, and most system level code is in C.

Another example: Imagine trying to write a safe multi-user operating system when your processor has only a single execution level.  No memory barriers between processes, no opcodes that require "root", any program can read & write any memory of another program, the OS, or hardware ports, everything just has to try and get along... That was the DOS & Win <= 3.x era.  Operating systems like VMS solved the issue with a VM, so that the OS could provide virtual OP-codes that the hardware did not have in order to provide access limitations to root OS memory, for example.  The result was far slower than a CPU chipset that has built in "root" and "user" execution permission levels / memory boundaries / etc. hardware features.

Point being: Current languages and their features are a product of the hardware environment.  Even VM langs like Java have pandered to the hardware for the sake of JIT compilation & execution speed.  Systems are getting fast enough that it doesn't matter so much, and caches are getting larger so that you can do more language things -- but we are still severely limited by how the dominant chipsets handle execution stacks (in a largely insecure fashion). We are hamstrug by old CPU designs.  There is much innovation to be had once hardware becomes more programmable, e.g. FPGA (field programmable gate arrays) and ASIC (algorithmic software [on an] integrated circuit) [combine the two, you've got language primitives in ASIC with the malleability of FPGA).
Logged
qMopey
Level 6
*


View Profile WWW
« Reply #279 on: April 29, 2018, 09:17:07 PM »

Could you elaborate? i don't know what you mean by "have one run by end of scope"?

Sure, take this:

Code:
void* mem = malloc(sz);
__run_on_scope_exit free(mem);

...

return 0;

something_bad_happened:
return 1;

And now free(mem) will always happen whenever the scope the free(mem) line belongs to exits, no matter what. It would work a lot like a some kind of fancy pre-processor, inlining the collection of all lines starting with the magic __run_on_scope_exit notation, just before all scope exit points.
Logged
Pages: 1 ... 12 13 [14] 15 16
Print
Jump to:  

Theme orange-lt created by panic