Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411276 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 12:20:45 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)The grumpy old programmer room
Pages: 1 ... 276 277 [278] 279 280 ... 295
Print
Author Topic: The grumpy old programmer room  (Read 733267 times)
Ordnas
Level 10
*****



View Profile WWW
« Reply #5540 on: December 12, 2017, 01:18:05 AM »

I guess I am grumpy. I have a question. Does anyone here know -- I hope someone does -- whether it is possible to create a DOS game, say a single level of Bubble Bobble, using QBasic? I know it is. But my question is, can I make it run fast enough on a PC 486? I'm using DosBox and whatever kind of graphics I try to draw using QBasic runs so slow I can see it "unfolding" on the screen. The image does not appear instantly. Rather, it literally "unfolds" in front of me. I can see it being drawn. And it does not matter whether I am using an interpreter or a compiler. It is the same either way. Do I have to use something else? Borland C++ with assembly? Google didn't help me much.

IMHO, you can make a Bubble Bobble clone using QBasic, there are games made in Basic so it is possible. 486 is more than enough for this kind of game, the 386 ran Wolfenstein 3d (even if there were a lot of performance wise design choice). If it is slow, did you check if in DOSBox you setted the correct Mhz emulation? Did you have previous experience in making a game from scratch, without using an already made engine like Unity? Because maybe the game is slow because there is something in the code that it's iterating too much.
Logged

Games:

Maximillian
Level 0
**


View Profile
« Reply #5541 on: December 13, 2017, 04:01:27 AM »

DosBox runs games such as Wolfenstein 3D and Doom pretty well. In DosBox configuration file, the CPU type is set to auto (which it is said is the fastest option.) Cycles, which is the number of instructions DosBox attempts to emulate each millisecond, is also set to auto. I tried using CTRL + F12 to increase this value while running DosBox but there isn't much difference when it comes to my QBasic program. Note that I am calling PSET in a double FOR loop to draw a square on the screen. Maybe this is a slow approach? I tried using FreeBasic and it runs the same code just fine. The only thing that has worked in QBasic is the approach that uses page-flipping.

This code runs fine:

Code:
DATA 00,00,00,00,00,00,00,00,00,00,12,12,00,00,00
DATA 00,00,00,00,00,00,00,00,00,00,15,15,00,00,00
DATA 00,00,00,00,00,00,00,00,00,15,15,15,15,00,00
DATA 00,00,00,00,00,00,00,00,00,15,15,00,15,00,00
DATA 00,00,00,00,00,00,00,00,15,15,15,15,15,14,00
DATA 00,00,00,00,15,15,15,15,15,15,15,15,15,14,14
DATA 15,00,15,15,15,15,00,15,15,15,15,15,00,00,00
DATA 00,15,15,15,15,00,15,15,15,15,15,00,00,00,00
DATA 15,00,15,15,00,15,15,15,15,15,15,00,00,00,00
DATA 00,15,15,15,15,00,00,15,15,15,15,00,00,00,00
DATA 15,00,15,15,15,15,15,15,15,15,00,00,00,00,00
DATA 00,00,00,00,00,00,15,15,15,00,00,00,00,00,00
DATA 00,00,00,00,00,00,00,14,00,00,00,00,00,00,00
DATA 00,00,00,00,00,00,00,14,00,00,00,00,00,00,00
DATA 00,00,00,00,00,00,14,14,14,00,00,00,00,00,00

SCREEN 7, 0, 1, 0
CLS

FOR y = 0 TO 14
  FOR x = 0 TO 14
    READ DotColor
    PSET (x, y), DotColor
  NEXT
NEXT

DIM imgDuck(15, 15)
GET (0, 0)-(15, 15), imgDuck
CLS

done = 0
speed = 2
x = 0
y = 0

KeyRight$ = CHR$(0) + CHR$(77)
KeyLeft$ = CHR$(0) + CHR$(75)
keyDown$ = CHR$(0) + CHR$(80)
keyUp$ = CHR$(0) + CHR$(72)

WHILE done = 0
  CLS
  PUT (x, y), imgDuck
  PCOPY 1, 0

  k$ = UCASE$(INKEY$)

  SELECT CASE k$
    CASE KeyRight$
      x = x + speed
    CASE KeyLeft$
      x = x - speed
    CASE keyUp$
      y = y - speed
    CASE keyDown$
      y = y + speed
    CASE "Q"
      done = 1
  END SELECT

WEND

But the code that only makes PSET calls does not?

The PSET-only approach looks like this:

Code:
duck:
DATA 00,00,00,00,00,00,00,00,00,00,12,12,00,00,00
DATA 00,00,00,00,00,00,00,00,00,00,15,15,00,00,00
DATA 00,00,00,00,00,00,00,00,00,15,15,15,15,00,00
DATA 00,00,00,00,00,00,00,00,00,15,15,00,15,00,00
DATA 00,00,00,00,00,00,00,00,15,15,15,15,15,14,00
DATA 00,00,00,00,15,15,15,15,15,15,15,15,15,14,14
DATA 15,00,15,15,15,15,00,15,15,15,15,15,00,00,00
DATA 00,15,15,15,15,00,15,15,15,15,15,00,00,00,00
DATA 15,00,15,15,00,15,15,15,15,15,15,00,00,00,00
DATA 00,15,15,15,15,00,00,15,15,15,15,00,00,00,00
DATA 15,00,15,15,15,15,15,15,15,15,00,00,00,00,00
DATA 00,00,00,00,00,00,15,15,15,00,00,00,00,00,00
DATA 00,00,00,00,00,00,00,14,00,00,00,00,00,00,00
DATA 00,00,00,00,00,00,00,14,00,00,00,00,00,00,00
DATA 00,00,00,00,00,00,14,14,14,00,00,00,00,00,00

SCREEN 7

done = 0
speed = 2
x = 0
y = 0

KeyRight$ = CHR$(0) + CHR$(77)
KeyLeft$ = CHR$(0) + CHR$(75)
keyDown$ = CHR$(0) + CHR$(80)
keyUp$ = CHR$(0) + CHR$(72)

WHILE done = 0
  CLS
  FOR i = 0 TO 14
    FOR j = 0 TO 14
      READ DotColor
      PSET (x + j, y + i), DotColor
    NEXT
  NEXT
  RESTORE duck

  k$ = UCASE$(INKEY$)

  SELECT CASE k$
    CASE KeyRight$
      x = x + speed
    CASE KeyLeft$
      x = x - speed
    CASE keyUp$
      y = y - speed
    CASE keyDown$
      y = y + speed
    CASE "Q"
      done = 1
  END SELECT

WEND

Correction: FreeBASIC runs it the same just a little bit better performance-wise. I guess the problem is PSET?
« Last Edit: December 13, 2017, 04:17:57 AM by Maximillian » Logged
Ordnas
Level 10
*****



View Profile WWW
« Reply #5542 on: December 14, 2017, 01:19:02 AM »

DosBox runs games such as Wolfenstein 3D and Doom pretty well. In DosBox configuration file, the CPU type is set to auto (which it is said is the fastest option.) Cycles, which is the number of instructions DosBox attempts to emulate each millisecond, is also set to auto. I tried using CTRL + F12 to increase this value while running DosBox but there isn't much difference when it comes to my QBasic program. Note that I am calling PSET in a double FOR loop to draw a square on the screen. Maybe this is a slow approach? I tried using FreeBasic and it runs the same code just fine. The only thing that has worked in QBasic is the approach that uses page-flipping.

This code runs fine:

Code:
DATA 00,00,00,00,00,00,00,00,00,00,12,12,00,00,00
DATA 00,00,00,00,00,00,00,00,00,00,15,15,00,00,00
DATA 00,00,00,00,00,00,00,00,00,15,15,15,15,00,00
DATA 00,00,00,00,00,00,00,00,00,15,15,00,15,00,00
DATA 00,00,00,00,00,00,00,00,15,15,15,15,15,14,00
DATA 00,00,00,00,15,15,15,15,15,15,15,15,15,14,14
DATA 15,00,15,15,15,15,00,15,15,15,15,15,00,00,00
DATA 00,15,15,15,15,00,15,15,15,15,15,00,00,00,00
DATA 15,00,15,15,00,15,15,15,15,15,15,00,00,00,00
DATA 00,15,15,15,15,00,00,15,15,15,15,00,00,00,00
DATA 15,00,15,15,15,15,15,15,15,15,00,00,00,00,00
DATA 00,00,00,00,00,00,15,15,15,00,00,00,00,00,00
DATA 00,00,00,00,00,00,00,14,00,00,00,00,00,00,00
DATA 00,00,00,00,00,00,00,14,00,00,00,00,00,00,00
DATA 00,00,00,00,00,00,14,14,14,00,00,00,00,00,00

SCREEN 7, 0, 1, 0
CLS

FOR y = 0 TO 14
  FOR x = 0 TO 14
    READ DotColor
    PSET (x, y), DotColor
  NEXT
NEXT

DIM imgDuck(15, 15)
GET (0, 0)-(15, 15), imgDuck
CLS

done = 0
speed = 2
x = 0
y = 0

KeyRight$ = CHR$(0) + CHR$(77)
KeyLeft$ = CHR$(0) + CHR$(75)
keyDown$ = CHR$(0) + CHR$(80)
keyUp$ = CHR$(0) + CHR$(72)

WHILE done = 0
  CLS
  PUT (x, y), imgDuck
  PCOPY 1, 0

  k$ = UCASE$(INKEY$)

  SELECT CASE k$
    CASE KeyRight$
      x = x + speed
    CASE KeyLeft$
      x = x - speed
    CASE keyUp$
      y = y - speed
    CASE keyDown$
      y = y + speed
    CASE "Q"
      done = 1
  END SELECT

WEND

But the code that only makes PSET calls does not?

The PSET-only approach looks like this:

Code:
duck:
DATA 00,00,00,00,00,00,00,00,00,00,12,12,00,00,00
DATA 00,00,00,00,00,00,00,00,00,00,15,15,00,00,00
DATA 00,00,00,00,00,00,00,00,00,15,15,15,15,00,00
DATA 00,00,00,00,00,00,00,00,00,15,15,00,15,00,00
DATA 00,00,00,00,00,00,00,00,15,15,15,15,15,14,00
DATA 00,00,00,00,15,15,15,15,15,15,15,15,15,14,14
DATA 15,00,15,15,15,15,00,15,15,15,15,15,00,00,00
DATA 00,15,15,15,15,00,15,15,15,15,15,00,00,00,00
DATA 15,00,15,15,00,15,15,15,15,15,15,00,00,00,00
DATA 00,15,15,15,15,00,00,15,15,15,15,00,00,00,00
DATA 15,00,15,15,15,15,15,15,15,15,00,00,00,00,00
DATA 00,00,00,00,00,00,15,15,15,00,00,00,00,00,00
DATA 00,00,00,00,00,00,00,14,00,00,00,00,00,00,00
DATA 00,00,00,00,00,00,00,14,00,00,00,00,00,00,00
DATA 00,00,00,00,00,00,14,14,14,00,00,00,00,00,00

SCREEN 7

done = 0
speed = 2
x = 0
y = 0

KeyRight$ = CHR$(0) + CHR$(77)
KeyLeft$ = CHR$(0) + CHR$(75)
keyDown$ = CHR$(0) + CHR$(80)
keyUp$ = CHR$(0) + CHR$(72)

WHILE done = 0
  CLS
  FOR i = 0 TO 14
    FOR j = 0 TO 14
      READ DotColor
      PSET (x + j, y + i), DotColor
    NEXT
  NEXT
  RESTORE duck

  k$ = UCASE$(INKEY$)

  SELECT CASE k$
    CASE KeyRight$
      x = x + speed
    CASE KeyLeft$
      x = x - speed
    CASE keyUp$
      y = y - speed
    CASE keyDown$
      y = y + speed
    CASE "Q"
      done = 1
  END SELECT

WEND

Correction: FreeBASIC runs it the same just a little bit better performance-wise. I guess the problem is PSET?

Probably that double innested FOR loop is causing some indirection everytime you read a new column. Try to use a single For loop? Wolrfenstein 3D, for the particular 4 bank VRAM of the hardware of that time, draws 4 pixels at the time, reducing cpu cycles. Also the switch case could be very slow for branch prediction reasons... did you try to remove the switch case for the keys, to see if that is the cause?
Logged

Games:

Maximillian
Level 0
**


View Profile
« Reply #5543 on: December 17, 2017, 07:29:00 PM »

Putting aside QBasic for a moment, my attention is drawn towards what most people nowadays use to create video games: Unity 3D. I am a Unity beginner and as a beginner I have a lot of questions. Unfortunately, they cannot be answered by anyone other than myself and this is for several reasons.

First, because official documentation is very poor. The rules remain obscure.

Second, because whatever is offered for free on the Internet is in the form of tutorials and I generally don't like tutorials because they do not explain the rules of the mechanism (such as Unity 3D) but merely give you the steps necessary to achieve this or that goal. Basically, they give you solutions that you can use in your project by simply repeating the steps as specified. This involves no thinking whatseover. All you have to do is just do what you are told to do. Do this or that and then you will get this or that. This can help you reach your goals but with regards to the rules that govern the program that you are using you remain clueless. You still don't understand the full breadth of consequences of particular actions. You just know that if you perform a bunch of actions in a particular sequence that you will get some complex end-result. And this is why I don't like tutorials. Especially when they are video tutorials.

Third, because whatever books there are on the subject are not much better than the tutorials that you can access for free. They appear to be mostly cookbooks, a collection of recipes where a recipe is a problem and a solution to a problem. They are not manuals that describe the consequences of various actions you can perform in the program.

There is thus noone other than myself that I can rely on except for a few people out there who really know how Unity works. This is also the main reason I find learning frameworks, libraries, engines and other high-level stuff unrewarding. The rules are generally not clearly explained, they remain opaque, so you have no choice but to use a trial-and-error approach to figure out how things work. That's not a very fun option when you compare it to that of learning to do everything on your own. Nonetheless, because Unity is very popular, and thus something you simply must know if you want to get a job in the industry, I have no choice.

Why is understanding the rules of the system more important than simply knowing how to achieve this or that goal using that system? Because by understanding the rules you can learn on your own how to achieve any goal you set for yourself that is possible to achieve by using the system. You do not have to rely on others. You become independent. You can devise a solution to any kind of problem. You do not have to use ready-made solutions. Knowing the rules also means you can predict the behavior of the system with near perfect accuracy. It means less unexpected behavior, i.e. bugs, and that means less frustration. I have no problem with learning rules but I do not enjoy learning man-made rules. I prefer learning natural rules. So I am more inclined to understand the kind of physics that govern the universe and then use that to build whatever I want to build than to learn someone else's invention that was built on top of that same physics. This is because the latter involves learning artificial, man-made, things that are generally poorly documented. It's not very interesting.
Logged
oahda
Level 10
*****



View Profile
« Reply #5544 on: December 18, 2017, 12:03:37 AM »

I've definitely seen lots of basic technical information for Unity in the manual, like flowcharts for the order of events in a frame of the main game loop and so on. Maybe you're looking in the wrong places? What sort of stuff are you missing? Is it an explanation of the engine systems (game objects, components, scripts and events…) or is it the interface itself?

I do personally think that it's both inadvisable and quite impossible to learn anything as complex as Unity (like 3D modelling packages and so on, or even programming itself) by reading up on everything first and then getting into it with the full knowledge: IMO it has to be done by practice to gain experience every step of the way. Don't start with a serious project that you expect to be spending a lot of time on, but play around a bit first and make some mistakes to learn from.

If you disagree, I'll still be happy to try and explain or point you in the right direction when it comes to any questions you have about Unity but you'd have to be more specific. There's just so much to cover.
Logged

bateleur
Level 10
*****



View Profile
« Reply #5545 on: December 19, 2017, 01:21:33 AM »

I do personally think that it's both inadvisable and quite impossible to learn anything as complex as Unity (like 3D modelling packages and so on, or even programming itself) by reading up on everything first and then getting into it with the full knowledge: IMO it has to be done by practice to gain experience every step of the way.
Very much this. If you want to make big things, make small things first.

I switched to Unity as my main development platform about seven years ago and would still consider myself not much beyond a beginner in most respects. It's a very complex system.
Logged

JWki
Level 4
****


View Profile
« Reply #5546 on: December 19, 2017, 01:29:31 AM »

Why am I grumpy today?
Welllll let's just say the bullet physics library doesn't want to play nice with my build settings.
More specifically, trying to use it in a project that has exceptions disabled turns out to be a nightmare because they did custom memory allocation in the shit way where they overload new for each fucking type but then also go ahead and just use regular placement new which requires <new> to be pulled in which unfortunately doesn't like exception-less build settings.

So this isn't helping the urge to write a rigidbody/cloth/softbody solver myself.
Which is probably what I'm going to do.

Disclaimer I'm just using this as an excuse I wanted to write a physics system at some point anyways. And it's not like I have a game to ship or anything.

I might just look into either modifying Bullet to be sane about allocation hooking though, or just put it into its own module that I build with exceptions enabled.
Logged
qMopey
Level 6
*


View Profile WWW
« Reply #5547 on: December 19, 2017, 01:30:43 AM »

PM me about the rigid body stuff if you wanna chat about it Smiley
Logged
Maximillian
Level 0
**


View Profile
« Reply #5548 on: December 19, 2017, 09:57:08 AM »

I do personally think that it's both inadvisable and quite impossible to learn anything as complex as Unity (like 3D modelling packages and so on, or even programming itself) by reading up on everything first and then getting into it with the full knowledge: IMO it has to be done by practice to gain experience every step of the way. Don't start with a serious project that you expect to be spending a lot of time on, but play around a bit first and make some mistakes to learn from.

I am not trying to learn Unity in its entirety. I am not trying to learn every single rule it has. What I am trying to do is to understand those rules that are of interest to me. And these rules that are of interest to me, they aren't numerous. At any point in time, there is only one rule that is of interest to me. I make sure that I am focusing on one thing at a time. I process information locally rather than globally. I start with the details and then move towards the big picture. Bottom-up and not top-down. I am a notorious reductionist. I break complex things down into the simplest possible components before I attempt to digest them. Bertrand Russell is one of my favorite philosophers. That should ring a bell. What I really want is a precise description of any particular rule that is of interest to me at any particular point in time so that I don't have to discover it on my own through a laborious process of trial-and-error. I want to know what happens if I do this or that without having to discover it on my own by running countless experiments. I don't want to spend a lot of my time trying to figure out the rules. I want to spend most my time predicting the consequences of these rules. You know how they say, games should be "easy to learn, difficult to master". The same applies to game engines. They should be easy to learn. Their rules must be transparent and not opaque. They can be as difficult to master as their developers want. And they can also have as many rules as their developers want. They can have so many rules that more than a lifetime is required in order to learn them all. But every single rule should be clearly explained. The game engine should not be a black box. I understand very well that this is just a "should" and not an "is". Things are as they are and you either use them to your advantage by accepting what they are or you don't. If I judge it to be necessary, I will learn a black box system. What I am doing here is I am simply noting why I prefer to do everything on my own. I'd rather write my own 3D engine from scratch, using assembly if necessary, than use an existing one that is opaque. Even if it will take so long that I will never finish it during my life. I am not rushing. What is important to me is that I am making progress i.e. that I am moving towards a goal. There is no specified timeframe within which I have to attain my goals. I may start with something big, with some kind of big goal I want to attain, but once I perform reduction on it, I turn it into a chain of tiny sub-goals that is so long that I forget about the destination I want to reach. Maybe I wanted to be the fastest person in the world but what I am doing right now is merely learning how to walk -- because knowing how to walk is the first step towards becoming the fastest person in the world. That's how I approach Unity. I may have some kind of big goal in my mind but because I am a Unity beginner this is mostly irrelevant. What is relevant is how Unity works and whether Unity can actually be used to attain my goals. What I am currently doing is "playing around" as you say. I am trying to understand what this or that button does. I am not asking "how can I use these buttons to make what I want to make?" No, what I am asking is "what will happen if I press this button?" Learning the system is the first step. Using the system without knowing how it works is foolish.
« Last Edit: December 19, 2017, 10:11:28 AM by Maximillian » Logged
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #5549 on: December 19, 2017, 11:41:45 AM »

It's funny, I just had a big argument with someone about a similar topic the other day. I was trying to argue that prescriptive programming advice without adequate justification is harmful and spreads dogmatism. His argument seemed to be that convention exists for a reason, so you can get a head start by doing what other people do without immediately questioning everything.

I've always been a nuts-and-bolts programmer, and I like to be able to understand every implication of what I do down to the most fundamental level. My viewpoint on this has evolved over the years, though. These days, the approach I take to learning something new is more accepting of convention and suggestion without full justification, so that I can have some kind of grounding before questioning and drilling down into every aspect of it. I try to keep track of the concepts I've used that are "unverified", or need further research to feel like I fully understand their implications, but I don't let that stop me from using them anymore.

Right now, I'm a journey of learning to be a 3D artist and animator. I had tried for years to figure out how to get started with it from a bottom-up approach, but I never was able to get any traction until I started following tutorials. The work that I produced from the tutorial wasn't the valuable part, and I pretty much just threw it away afterward; what I really got out of following the prescribed steps was a framework for asking further questions and getting a handle on why conventions are the way they are. Building on this top-down understanding, I've been able to more coherently phrase questions to experts in the field I'm studying, so that they can help explain how a convention came to be and why it's useful. In some cases, I've also been able to pick apart the prescribed steps of what I'd just done, and rearrange them into a workflow that worked better for me than the commonly agreed convention that's taught in tutorials.

What I guess I'm trying to get at is that a top-down learning methodology can actually be used to bootstrap bottom-up understanding, and potentially get you to where you want to be much quicker than just sticking with a purely bottom-up approach. As long as you're judicious about verifying prescriptive concepts and picking them apart into their components, you won't have to use dogmatic thinking as anything other than a framework for further research. This does involve some extra overhead, but again, I'm finding that the overhead of this approach tends to be significantly less than the overhead of building up your high-level understanding purely from low-level concepts. Both roads lead to the same place, but one is potentially shorter than the other. Sure, there are shortcuts on the short road that might allow you to continue without gaining a low-level understanding of what you're doing, but if you're already thinking about things in this way, those shortcuts won't be appealing to you - you'll end up with a complete understanding of the system you're trying to learn, and the common conventions that are used, so that you can talk to other people who use that system and understand each other.
Logged

Maximillian
Level 0
**


View Profile
« Reply #5550 on: December 19, 2017, 02:29:26 PM »

I don't do everything on my own. For example, the computer that I am using as I type this post, I didn't build it on my own. And though it is true that I prefer to be independent (to do everything on my own) rather than to be dependent (to rely on others) I currently have little to no interest in building every single tool that I use. Instead, I prefer to buy these tools from people who make such tools.

What does this mean? It means that what we do on our own is a matter of personal preference.

I want to write a 3D engine from scratch. However, I have no interest in learning how necessary physical components such as monitors, graphics cards, processors and so on work. I don't want to create these physical components myself. Fortunately, I don't even need them. I'd be happy to write such an engine on a fantasy machine -- a machine that is entirely within one's imagination, akin to that of Alan Turing -- so as long it meets certain requirements. I want a machine that has simple rules but complex consequences. A machine that can be programmed using simple instructions, instructions that are preferrably declarative rather than imperative; a machine that has a simple fantasy computer screen attached to it that can be addressed on per-pixel basis; and a basic fantasy keyboard would be a plus. That's all I need. A software emulator might be useful to test programs that aren't simple enough but perhaps a better approach would be to break them down into programs that are sufficiently simple to be run entirely within one's mind.

Logged
LittleTwig
Level 0
**


View Profile
« Reply #5551 on: December 20, 2017, 12:24:23 AM »

Might be kinda unrelated, but I'm kinda grumpy today. I woke up last night with a panic attack and thought I would get a heart attack, because my chest felt really tight and it was harder to breath..


Turns out it was caused by long programming sessions the days prior and relaxing/stretching could have prevented that. Never had any issues or pain with something like that before and I even exercise regularly.
Logged
Ordnas
Level 10
*****



View Profile WWW
« Reply #5552 on: December 20, 2017, 01:29:37 AM »

I want to write a 3D engine from scratch. However, I have no interest in learning how necessary physical components such as monitors, graphics cards, processors and so on work. I don't want to create these physical components myself. Fortunately, I don't even need them. I'd be happy to write such an engine on a fantasy machine -- a machine that is entirely within one's imagination, akin to that of Alan Turing -- so as long it meets certain requirements. I want a machine that has simple rules but complex consequences. A machine that can be programmed using simple instructions, instructions that are preferrably declarative rather than imperative; a machine that has a simple fantasy computer screen attached to it that can be addressed on per-pixel basis; and a basic fantasy keyboard would be a plus. That's all I need. A software emulator might be useful to test programs that aren't simple enough but perhaps a better approach would be to break them down into programs that are sufficiently simple to be run entirely within one's mind.

But if you want to write a game engine from scratch you need to know how the hardware works, and that it works like that even 20 years ago. If you writing the rendering you should know how the graphics pipeline works, or you will not have nothing on the screen, or if you write an input system have an idea of how the processor are acquiring this input from the keyboard.

Today writing a 3d framework it is very hard, it is not like years ago, a couple of friends programming in a garage, because now the complexity increased so much that you need to divide each sub-system (graphics, audio, physics etc.) to different people. It is like in a movie making: it is very hard to be the Director, the Screenwriter, the Actor, plus all the other positions that are behind the camera.

If you want to make a game, just use Unreal, Unity. To learn how to use it, read the documentation for the theory + the video tutorials for the practice. You will definitely create stuffs on this way.
Different if you want to learn more, how things work under the hood. That you need to study what a programmer must study indipendently from the specialization he/she will do: see what computer science university courses are doing, or this books to get an idea: http://mrelusive.com/books/books.html If you know these things, it is higly probable that you can solve problems in other specialization, that could be englineering, video games, networking etc.
Logged

Games:

JWki
Level 4
****


View Profile
« Reply #5553 on: December 20, 2017, 03:06:49 AM »

PM me about the rigid body stuff if you wanna chat about it Smiley

Will do I might get to work on it a bit over the holidays!
For now I have to be a very grumpy programmer working on non-realtime fluid sim (meh).
Logged
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #5554 on: December 20, 2017, 09:15:12 AM »

Today writing a 3d framework it is very hard, it is not like years ago, a couple of friends programming in a garage, because now the complexity increased so much that you need to divide each sub-system (graphics, audio, physics etc.) to different people.

I think this is misleading. If you're comparing writing a cutting-edge modern game engine today that can compete with the likes of Unreal, Unity, etc. to writing what would have been cutting edge 10 or 15 years ago, there might be some truth to this, but that seems reductive.

Some things that are different:
  • Hardware has gotten faster and more capable.
  • APIs have evolved. OpenGL 3 and 4 are a little bit less beginner-friendly than 1 and 2 were.
  • More and better learning resources have been created. See learnopengl.com as a prime example.
  • More high quality free and open source libraries are available to use, or pick apart to figure out how they work.
  • Conventions have been established and adopted. We have more vocabulary for talking about these things, and more people understand and work with it every day.
  • Player expectations have grown in response to cutting edge technology and big budget productions.

As you can see, it's complicated. Some things are harder, and some things are easier. Trying to directly compete with big budget AAA games as an individual of course doesn't make sense, but why would you want to? There's a huge amount of space to carve out a niche someplace else. Minecraft is a perfect example of a game that was absolute garbage both technically and aesthetically, but went on to be one of the most successful games of all time. It demonstrates that you don't need a whole team of experts on cutting edge technology to create something that reaches your audience.
Logged

JWki
Level 4
****


View Profile
« Reply #5555 on: December 20, 2017, 09:43:37 AM »

Today writing a 3d framework it is very hard, it is not like years ago, a couple of friends programming in a garage, because now the complexity increased so much that you need to divide each sub-system (graphics, audio, physics etc.) to different people.

I think this is misleading. If you're comparing writing a cutting-edge modern game engine today that can compete with the likes of Unreal, Unity, etc. to writing what would have been cutting edge 10 or 15 years ago, there might be some truth to this, but that seems reductive.

Some things that are different:
  • Hardware has gotten faster and more capable.
  • APIs have evolved. OpenGL 3 and 4 are a little bit less beginner-friendly than 1 and 2 were.
  • More and better learning resources have been created. See learnopengl.com as a prime example.
  • More high quality free and open source libraries are available to use, or pick apart to figure out how they work.
  • Conventions have been established and adopted. We have more vocabulary for talking about these things, and more people understand and work with it every day.
  • Player expectations have grown in response to cutting edge technology and big budget productions.

As you can see, it's complicated. Some things are harder, and some things are easier. Trying to directly compete with big budget AAA games as an individual of course doesn't make sense, but why would you want to? There's a huge amount of space to carve out a niche someplace else. Minecraft is a perfect example of a game that was absolute garbage both technically and aesthetically, but went on to be one of the most successful games of all time. It demonstrates that you don't need a whole team of experts on cutting edge technology to create something that reaches your audience.

So much this. You can't write something that is as fully featured as some commercial engine, but why would you need to. Even games done with these engines don't use more than a fraction of their features often times. It all depends on your background and interests. If you care about tech or work in a team with someone dedicated to tech, rolling your own can be more effective even than using a commercial engine.
Logged
powly
Level 4
****



View Profile WWW
« Reply #5556 on: December 20, 2017, 11:16:20 AM »

  • APIs have evolved. OpenGL 3 and 4 are a little bit less beginner-friendly than 1 and 2 were.
[citation needed]. Stuff might be less concrete, but on the other hand there aren't a billion interacting states, not a dozen ways of doing a given thing (which was pretty nasty at GL2) and less gotchas that follow from arbitrary design decisions. If you know linear algebra and anything about the typical graphics pipeline, they might be easier to get into.
Logged
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #5557 on: December 20, 2017, 11:28:33 AM »

[citation needed]. Stuff might be less concrete, but on the other hand there aren't a billion interacting states, not a dozen ways of doing a given thing (which was pretty nasty at GL2) and less gotchas that follow from arbitrary design decisions. If you know linear algebra and anything about the typical graphics pipeline, they might be easier to get into.

Right, I meant from the perspective of someone who doesn't know those things already. I'm mostly thinking of difference between setting up a VBO and a couple of shaders, and drawing stuff with immediate mode and the fixed function pipeline. The new system is definitely better once you get a foothold, but for a new programmer trying to make that initial step to just get a triangle to draw, it's a much more complicated process with way more points of failure. Using some sort of pre-written template or tutorial could bridge the gap.
Logged

Maximillian
Level 0
**


View Profile
« Reply #5558 on: December 20, 2017, 01:31:51 PM »

But if you want to write a game engine from scratch you need to know how the hardware works, and that it works like that even 20 years ago. If you writing the rendering you should know how the graphics pipeline works, or you will not have nothing on the screen, or if you write an input system have an idea of how the processor are acquiring this input from the keyboard.

Do I? I think it depends on my needs. I can write a software emulator of my fantasy machine using nothing more than HTML5 Canvas and JavaScript. I don't have to know anything about hardware in order to use these two technologies. Of course, I understand, such a software emulator would be slower than the one written in C++ or assembly. And software emulators in general would be slower than hardware emulators. But the question is: do I care about this performance difference? How significant such a difference would be in relation to my needs? If it is insignificant then HTML + JS is the best choice. But if it is significant, say because I want to create an engine that can be used to create video games that can compete with AAA titles in terms of graphics, then sure, HTML + JS wouldn't be the best choice. Thankfully, my needs are modest. I want to create a 3D engine but I do not want to create an engine that you can use to create cutting-edge video games or even games that consumers can play on their own machines. My goal is to acquire understanding, not to create commercial games.

Quote
Today writing a 3d framework it is very hard, it is not like years ago, a couple of friends programming in a garage, because now the complexity increased so much that you need to divide each sub-system (graphics, audio, physics etc.) to different people. It is like in a movie making: it is very hard to be the Director, the Screenwriter, the Actor, plus all the other positions that are behind the camera.

I agree.

Quote
If you want to make a game, just use Unreal, Unity. To learn how to use it, read the documentation for the theory + the video tutorials for the practice. You will definitely create stuffs on this way.

If I want to create a commercial game that's exactly what I'd use. Or HTML + JS if the game is simple enough.
Logged
Ordnas
Level 10
*****



View Profile WWW
« Reply #5559 on: December 21, 2017, 01:02:33 AM »

Today writing a 3d framework it is very hard, it is not like years ago, a couple of friends programming in a garage, because now the complexity increased so much that you need to divide each sub-system (graphics, audio, physics etc.) to different people.

As you can see, it's complicated. Some things are harder, and some things are easier. Trying to directly compete with big budget AAA games as an individual of course doesn't make sense, but why would you want to? There's a huge amount of space to carve out a niche someplace else. Minecraft is a perfect example of a game that was absolute garbage both technically and aesthetically, but went on to be one of the most successful games of all time. It demonstrates that you don't need a whole team of experts on cutting edge technology to create something that reaches your audience.

I agree, you right, Minecraft is an example. I thought that Maximillian was very interested in the low-level side at first, reading his implementation in QBasic.



But if you want to write a game engine from scratch you need to know how the hardware works, and that it works like that even 20 years ago. If you writing the rendering you should know how the graphics pipeline works, or you will not have nothing on the screen, or if you write an input system have an idea of how the processor are acquiring this input from the keyboard.

Do I? I think it depends on my needs. I can write a software emulator of my fantasy machine using nothing more than HTML5 Canvas and JavaScript. I don't have to know anything about hardware in order to use these two technologies. Of course, I understand, such a software emulator would be slower than the one written in C++ or assembly. And software emulators in general would be slower than hardware emulators. But the question is: do I care about this performance difference? How significant such a difference would be in relation to my needs? If it is insignificant then HTML + JS is the best choice. But if it is significant, say because I want to create an engine that can be used to create video games that can compete with AAA titles in terms of graphics, then sure, HTML + JS wouldn't be the best choice. Thankfully, my needs are modest. I want to create a 3D engine but I do not want to create an engine that you can use to create cutting-edge video games or even games that consumers can play on their own machines. My goal is to acquire understanding, not to create commercial games.

Mmm, IMHO I am not even sure if I could consider that example of an HTML5 + JS an engine... when I think about a game engine from scratch I think about all or most of the implementation directly connected to the hardware using a library: rendering talking directly to the GPU using DirectX/OpenGL, input using XInput etc. I do not know if you are making a game in HTML + JS, you have to use a library that itì's wrapping some framework that, essentially, it could be the same as using an already architecture (aka game engine).
Logged

Games:

Pages: 1 ... 276 277 [278] 279 280 ... 295
Print
Jump to:  

Theme orange-lt created by panic