senpie

“Chapter 10: Expression” was definitely my least favorite chapter so far. Don't get me wrong I had a great time writing, that calculator thingie, however, the rest was horrible. I did not enjoy reading several pages of the operator precedence table, which I will for sure forget. Nor did I enjoy trillion conversion rules when doing operations (ու չգիտես խի մենակ javascript-ի անունն ա հելել). Not talking about the undefined order of operations in subexpressions. The concept of consexpression was confusing as hell too. Super boring, wouldn't recommend 0/10.

Day six of hating on this book and on OS X. I finished the calculator program, however the code example provided in the book was incomplete. I had to do some tinkering to fix it, although I guess I can count it as an exercise. After I fixed the code, I spent more time trying to compile it, because seems like even to compile a simple program on mac you don't use gcc, not g++ nor clang, but specifically clang++. I always thought, that on most systems including Mac, g++ is a symbolic link to gcc with different flags, and I never even knew about the existence of clang++. Not to mention, that I am already 255 pages in yet it doesn't talk about how you compile your program. That's it for today, be safe, update your Xcode, and use clang++ on mac!

Today was rather interesting. It's the chapter of “Expressions” and I was expecting something trivial, but to my surprise, there's a quite elaborate example of a calculator. It's not one of those simple calculator examples where you type number hit Enter type another number and get a result, but simple language where you can even have assignments. An example input out looks something like this:

r = 2.5
area = pi * r * r

Note, that pi is predefined. The output would be

2.5
19.635

For that, it actually shows how to write a lexer, parser, error handling, and everything else needed to process the input and produce output. Shout out to Norayr(Inky) for his awesome “Compiler Design” class. If you are doing CS in AUA make sure to check it out. It definitely helps me to understand the terminology used in this chapter and the techniques Bjarne is applying. What is surreal to me, is that this book expects you to have background experience with compiler design in the earliest chapters. Although it is mentioned several times in the beginning, that “if this is your first time programming, better read another book”, I still believe that most of the programmers out there and even experienced ones haven't really studied compiler design. Also, I wish the book used EBNF, when describing the grammar, or else it looks confusing. That's it for today, I haven't really finished the chapter yet, since this time I am trying to implement the example on my own while reading so it takes a bit more time. See you later!

C++ is so ugly and beautiful once in a while, usually, it's just ugly. Today's topic included union type, enumerations, statments, condition statements, and loops. To start off union is disgusting. I understand why it can save some memory, but the amount of complexity it adds to the code is insane, not to mention most of the users do not use it properly anyway. In modern apps, if you have a union it means the poor design of a program since there are many other ways to organize the system and we have plenty of memory on top. Speaking of beauty and ugly, I wanted to talk about enums. Specifically enum class, which differentiates between Trafic_light::RED and Warning::RED as different REDs. Of course, there are plenty of ways to hack it, convert it to integers, and cast it back into a wrong range resulting in hard-to-find bugs. But it also allows me to write more expressive code, which I couldn't dream of doing in Java, specifically this code example which I can already see how I would use in games.

enum class Printer_flags {
    acknowledge=1,
    paper_empty=2,
    busy=4,
    out_of_black=8,
    out_of_color=16,
};

constexpr Printer_flags operator|(Printer_flags a, Printer_flags b)
{
    return static_cast<Printer_flags>(static_cast<int>(a) | static_cast<int>(b));
}

constexpr Printer_flags operator&(Printer_flags a, Printer_flags b)
{
    return static_cast<Printer_flags>(static_cast<int>(a) & static_cast<int>(b));
}

void f(Printer_flags p)
{
    // if printer is out of ink, then scream
    if (p & (Printer_flags::out_of_black|Printer_flags::out_of_color))
    {
        std::cout << "SCREAM\n";
    }
}

Note, while testing the code, I noticed several issues as to why the code wouldn't compile. First, in the original code example ( page 220 overloading operators |, & ), they had extra parenthesis. Furthermore, since the enum class cannot be implicitly converted to bool, the following statement will fail p & (Printer_flags::out_of_black|Printer_flags::out_of_color). Going forward to condition statements, they had a typo in a comment ( page 225 ). Seems like since these are relatively simple topics of the book, they haven't been proofread properly, which sucks.

More than ten years have passed since Oculus VR launched a Kickstarter in 2012 for their Virtual Reality (VR) headset, named the Rift. The market for VR is expected to grow over 20% between 2020-2027 and by 2025 the number of private owned devices will most likely reach 43 million^[1]. More and more games are being made for VR, while other pre-existing games are being ported to the new platform. The hardware for VR devices are getting better year by year, however it is quite far from being perfect. As Lazaraff highlights^[3], the perfect VR headset should have a resolution of 16k by 16k per eye with a dream of 1000 frames per second to achieve a compelling experience. Lazaraff also talks about latency, which can cause the user to vomit, explaining it with a fan-made theory. It says that while playing, your reptilian brain kicks in and thinks you are hallucinating, therefore making you vomit, thinking you have eaten something poisonous. Michael Abrash, a developer at Valve and former chief scientist at Oculus VR, brought a detailed report in his GDC talk^[4] about the limitations of current VR technologies and the set of new open-ended problems that are yet to be fixed. He splits the problems into “really hard problems” and “really really hard problems”. The 'really hard' problems include tracking, latency, and producing perceptions indistinguishable from reality. The VR displays move differently, since they move relative to both real reality (RR) and eyes, while also moving with your head, while images have to appear and remain in correct position at all time. This leads us to tracking, which refers to head position and orientation in real space. Generally, a gyroscope and accelerometer are used to calculate the inertial measurement unit (IMU), which is essential for mobile VR headsets to track head position and orientation. Because of that the head translation information is lost, meaning you cannot peek around the corners, you cannot duck down or look up over things. Also, there are drifting issues where the orientation in-game cannot stay stable with respect to real reality, ruling out AR board games. Although the talk was done on 2013, the base techniques described here are still relevant and are used in modern VR headsets, such as Playstation VR which again uses accelerometer and gyroscope for tracking. Another really hard problem is latency, which is the delay between head motion and the virtual world update reaching the eyes. Latency issues can result in motion sickness^[5], where your visual senses are in conflict with other spatial senses. This is a serious hardware issue, since latency should be somewhere between 1 & 20 ms for total tracking, rendering, transmitting to the display, getting photons coming out of display. Furthermore, the head can easily move 100 degrees per second. Temporal sampling done by displays can be an issue because colors are emitted separately, resulting in color fringing. Regardless, there is one specific problem which is my area of interest, that Michael Abrash addressed as a 'really, really hard problem': 'Figuring out what's uniquely fun about VR.' PC games innovated play and entertainment, earning their place in the league of contemporary art. It allowed to create experiences impossible before. With VR, game designers can take that experience even further and redefine the notion of games and entertainment. To maximise its potential it is crucial to take into account its limitations, some of which were mentioned before and its strengths available only with headset. John Carmack, who, besides his background at id Software, held the CTO position at Oculus VR, mentioned in his podcast interview with Lex Fridman^[6] that the game 'Beat Saber' is an example of a game that played on the strengths of VR and hid its weaknesses. He stresses the importance of controls, mentioning initial ideas where the user would have a gamepad, and it would already be cool to just move one's head around and look into the virtual environment. In Beat Saber, the player has a solid grip on the controllers the entire time and slices through objects without bumping into them. Whereas when you knock on a table in a game but your hand goes right through it, it breaks the immersion since the brain tells you that you should have felt some pressure on your hand. He also talks about audio and music being powerful aspects of VR. It is a powerful tool in game designers' arsenal to block the outside world off and construct a new one around you. Mobile VR headsets also have the issue of battery life; therefore, VR games need to run efficiently, even on relatively low-powered hardware, and should have a valuable loop in a small amount of time, whereas many games nowadays are packed with hours in a session. VR headsets can inflict discomfort after long sessions. In Beat Saber, the player rarely moves and mostly stands still. It has entertaining music, and the game loop is small. On the other hand, solving the mystery of the unique fun of VR touches on the issue of when certain experiences become worse when brought to the realm of virtual realities. There is a certain tendency of different companies to bring their brands into the virtual environment^[2]. Attempt has been done to make a tool for teaching students signal processing by trying to build intuition for digital filter design^[7], however conclusion shows “that many of the functionalities in this project could have been done without using virtual reality. In fact it could probably have been made even better if instead of using virtual reality the user is only sitting in front of a computer”. Linus Augustsson^[5], in his 'Design with Virtual Reality in Mind', argues that virtual reality can greatly enhance the gaming experience. However, a virtual reality solution does not suit every game, and there are certain types of games that are better experienced on a monitor. The only way to make them 'fun' in VR is through modification of their mechanics. Therefore, when designing a game for a headset, the game designer should aim to create a sense of presence while taking away anything that threatens to break immersion. In conclusion, my degree project proposal aims to research through design and develop several rules of thumb and an arsenal for game designers when making a VR game, taking into account the techniques practiced in previous successful titles and addressing technical challenges faced with current hardware.

[1] Oleksandr Dluhopolskyi, Anastasiia Simakhova, Tetiana Zatonatska, Serhii Kozlovskyi, Ihor Oleksiv, and Jurijs Baltgailis. 2021. Potential of Virtual Reality in the Current Digital Society: Economic Perspectives. In 2021 11th International Conference on Advanced Computer Information Technologies (ACIT), 360–363. DOI:https://doi.org/10.1109/ACIT52158.2021.9548495 [2] IKEA. 2017. IKEA invites people to make virtual pancakes releases a virtual reality app on Steam. Retrieved November 5, 2023 from https://www.ikea.com/global/en/newsroom/innovation/ikea-invites-people-to-make-virtual-pancakes--releases-a-virtual-reality-app-on-steam-170530/ [3] Rob and Jason are joined by Nicolas Lazaraff to discuss the current state of VR development with C++ https://cppcast.com/nicolas-lazaraff/ [4] Why Virtual Reality Is Hard (And Where It Might Be Going) https://gdcvault.com/play/1017797/Why-Virtual-Reality-Is-Hard https://media.steampowered.com/apps/valve/2013/MAbrashGDC2013.pdf [5] Augustsson, L. (2015). Design with Virtual Reality in Mind (Dissertation). Retrieved from https://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-254500 [6] John Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets | Lex Fridman Podcast #309 https://www.youtube.com/watch?v=I845O57ZSy4&t=12178s [7] Dalbom, A., Sprogis, M., Stolpe, E., & Söderkvist, N. (2018). A Tool for Learning Digital Filters in Virtual Reality (Dissertation). Retrieved from https://urn.kb.se/resolve?urn=urn:nbn:se:uu:diva-353852

Day 3 wasn't less productive and I managed to cover a set of topics including references combining lvalues and rvalues and more pointers, and a lot of structs. Hi, my name is reference, friends usually call me T& where T is my type. I may look simple, but sometimes I'm lvalue orrr rvalue. To be more technical lvalue reference, refers to an lvalue, to which the user of reference can write. Its brother is a bit weird at first glance, but it's quite useful and its name is “rvalue reference*, which refers to a temporary object, where the user of reference can modify it assuming the object will never be used again. I wonder if it was the end of the world, then we would all be rvalues. In short, you would use rvalue reference, when you do not want to copy the value of something that will be lost anyway, but rather you store that value for your usage. Not confusing at all right? Awesome, since you're here, I'm gonna introduce you to our neighbor Mr. Structs. Say hi to Mr. Structs. Hi, Mr. Structs with a screeching voice. Mr. Structs is like Mrs. Class, but more public. Also, Mr. Structs has a history waaay back in the ages of C, where it was used to store data. I've typed too much already, so will tell you two things. Pay attention to your struct layout to have fewer holes and save some memory. Structs can be used as “Plain Old Data” with cool bit-fields and you can use memcpy() and call yourself a hardcore programmer. Also, struct arrays are cool and in C++ your structs can have a bunch of other stuff, besides fields. That was three things, but well not removing it anymore. See you!

Day two wasn't much different from Day 1. I continued reading the book and supposedly it may take me several more days to finish, considering it's 1000+ pages:) Today, I read about how to deal with pointers and pointer arithmetic. Then, I touched on the array-to-pointer relationship crap, where an array usually means “the pointer to the first element” thing. If everything was not already bad, it becomes worse with two-dimensional arrays, where > you cannot really do void some_function(int m[][]), when passing arrays > and have to go with void some_function(int** m) and other syntactically weird things. Then it talks about const, when used to tell that value is initialized once, or if the pointer is constant resulting in this absolutely beautiful creature const char *const cp. Almost forgot to tell you about raw strings which was probably one of nicer things from the crowd, allowing users to write more readable regular expressions.

On my first day I resumed reading the book “The C++ programming Language” Fourth Edition by Bjarne Stroustrup. If I want to make my own engine with beautiful graphics I should master the concepts of C++ before. I read about difference between the definition and declaration. Also, where it is preferred to use the auto keyword and when initialization syntax with { } is preferred. Furthermore, I learned about different scopes, when value must be initialized manually and when it can be left empty. Chapter also explained the semantics of lvalues, rvalues and their other cases. “Lifetimes of objects” were also discussed. The chapter ended with comment on use of type aliases.

A follow up on the previous post, props to @antranigv for giving me the idea for the name of the series:)

It is happening! I am starting a blog series of “100DaysOfGameDev.” Everyday, I will do one hour of game dev from a topic that interests me. It can be about programming, engine development, computer graphics, audio engineering, 3D arts, game design or whatever else I feel like doing. Later each day, I will share with my progress here. Let's see where it takes me folks!