How's your game coming along?

Oh god are you using the incremental ray cast method?

>source is in C
>he wants to downgrade bloat it with sepples
disgusting
are you going to switch the build system to cmake as well?

I'm a newfag at raycasting so I'm not trying to optimise stuff right now, I'm sure there's a better way to do this but I don't know them. What are some better methods at raycasting?

make a list of lines and test the ray against each line

I'll stay true to the creator and only support VC2010 express.
>downgrade
#ifndef _EFFECT_H_
#define _EFFECT_H_

#include "DBLLINK.H"
#include "GENERAL.H"
#include "RESOURCE.H"

#define MAX_ITEM_EFFECTS 8
#define MAX_EFFECT_POWER 28000
#define MAX_EFFECT_DURATION 28000

typedef T_byte8 E_effectDamageType ;
#define EFFECT_DAMAGE_UNKNOWN 0
#define EFFECT_DAMAGE_NORMAL 1
#define EFFECT_DAMAGE_FIRE 2 /* 25% bonus damage */
#define EFFECT_DAMAGE_ACID 4 /* 1% chance per 100 hp lose item */
#define EFFECT_DAMAGE_POISON 8 /* 1 poison point per 10 pts damage */
#define EFFECT_DAMAGE_ELECTRICITY 16 /* light = +25% damage, heavy=+50% */
#define EFFECT_DAMAGE_PIERCING 32 /* ignore armor */
#define EFFECT_DAMAGE_MANA_DRAIN 64 /* 1 point mana loss per 1 pt damage */
#define EFFECT_DAMAGE_SPECIAL 128
#define EFFECT_DAMAGE_BAD 256
#define EFFECT_NUMBER_OF_DAMAGE_TYPES 7
#define EFFECT_DAMAGE_ALL (127)

#define EFFECT_DAMAGE_SPECIAL_LOCK 0
#define EFFECT_DAMAGE_SPECIAL_UNLOCK 1
#define EFFECT_DAMAGE_SPECIAL_DISPEL_MAGIC 2
#define EFFECT_DAMAGE_SPECIAL_PUSH 3
#define EFFECT_DAMAGE_SPECIAL_PULL 4
#define EFFECT_DAMAGE_SPECIAL_EARTHBIND 5
#define EFFECT_DAMAGE_SPECIAL_CONFUSE 6
#define EFFECT_DAMAGE_SPECIAL_BERSERK 7
#define EFFECT_DAMAGE_SPECIAL_SLOW 8
#define EFFECT_DAMAGE_SPECIAL_PARALYZE 9
#define EFFECT_DAMAGE_SPECIAL_UNKNOWN 10

This is a complete mess and the game needs namespaces. Also I want to show my epic for the win ++c skills on github.

What do you mean by lines though? A distance from the player?

>This is a complete mess
It's not.
>the game needs namespaces
There are namespaces.
You are looking at the "EFFECT_DAMAGE" namespace.
>show my epic for the win ++c skills
Call it "increasing the number of lines of code without *ANY* increase in functionality".

Walls and enemies.

>>he wants to downgrade bloat it with sepples
With C++'s ability to use more tools than C, you can easily write code. What the fuck do you mean bloat?

>are you going to switch the build system to cmake as well?
CMake is the industry standard for C++ projects.

Constructors would cut some parts of the code in half to be honest.

Shitty graphics.

>>This is a complete mess
>It's not.
It is. Don't lie to yourself. It isn't healthy to do so.

>>the game needs namespaces
>There are namespaces.
>You are looking at the "EFFECT_DAMAGE" namespace.
While this is a semblance of namespacing, this is just prefixing symbols.

>show my epic for the win ++c skills
>Call it "increasing the number of lines of code >without *ANY* increase in functionality".
Sure, if it's just a pure port from C to C++ without the addition of features. If the code is refactored then adding new features will be easier.

>this is what C fags advertise as good code

Attached: Untitled.png (687x745, 23K)

>bloat
unnecessary features that introduce more complexity than it's worth
>With C++'s ability to use more tools than C
lol what?
you need an editor and a debugger
>CMake is the industry standard for C++ projects.
Reflects how shit C++ is.
Nobody but few people (its original creators) know how cmake actually works.
Likewise, only some select few clang and gcc contributors and people in the design committee know how C++ works.
Compare the number of how many hobby C compilers (tcc, 8cc, vbcc, scc and many more) there are to how many hobby C++ compilers are there (0).
Well, that's just words. We'll see if you make something out of it, which I really doubt.

You can write good code in C it's just harder to do so because the simplicity of the language is a debilitating one not a helpful one. Just like writing C++ code won't make it automatically good code, but if you use the tools provided to you by the language, you can very well write good code.

>it's another "c fag defends using 10 keywords to do the job of 1" episode
>""""bloat""""

No but I spend all day writing OpenGL and OpenCL accelerated programs so it honestly wouldnt be hard.

Ive seen far far worse C++ code than C. Plenty of bad C to be sure but it remains legible.

>>bloat
>unnecessary features that introduce more complexity than it's worth
Like?

>>With C++'s ability to use more tools than C
>lol what?
>you need an editor and a debugger
What I meant by this is you get a lot more features than in C.

>>CMake is the industry standard for C++ projects.
>Reflects how shit C++ is. Nobody but few people (its original creators) know how cmake actually works.

Do you really need to know the internal workings of a build system?

>Likewise, only some select few clang and gcc contributors and people in the design committee know how C++ works.
The only people who need to know all the granular intricate details of C++ unless they're compiler creators.

>Compare the number of how many hobby C compilers (tcc, 8cc, vbcc, scc and many more) there are to how many hobby C++ compilers are there (0).
C++ is a huge language. It would take years to have a compiler that supports all modern C++ features AND keep it up to date.

fucka oyou

>The only people who need to know all the granular intricate details of C++ unless they're compiler creators.
*unless they're=are

I don't know how to code, but that case statement cheat makes me want to vomit

This

What happened to /agdg/ ?

i genuinely enjoy that you make this thread every other day on atleast 3 boards with varying ops.
but not i am not making a game because i'm retarded.

Attached: 1430800486047-1.png (500x644, 242K)

>i can't code but i feel the need to contribute anyway
are you a webdev?

>Like?
Templates, classes, RAII, operator overloading, function overloading, namespaces...
>Do you really need to know the internal workings of a build system?
>The only people who need to know all the granular intricate details of C++ unless they're compiler creators.
No.
You need to know what you're building, how you're building.
Otherwise it's like writing a book in a foreign language that you only know a few words in.
>C++ is a huge language. It would take years to have a compiler that supports all modern C++ features AND keep it up to date.
Exactly. It's bloated.

suckless.org/philosophy/

I'm a sysadmin, I don't see harm in contributing considering OP makes this thread every day

>Templates
If it's overused and abused, sure it can be bad.

>classes
Grouping data, functions that act up that data, and abstractions are bad because?

>RAII
Great idiom to automatically delete/close resources.

>operator overloading
If I have a matrix class and want to have the ability to add another matrix to it, writing m.add(anotherMatrix) is ugly. Overloading the addition operator would make the code look clean.

>function overloading
This can be used in the wrong way, but it is helpful at times.

>namespaces
This prevents name collisions and help organize code.

>>C++ is a huge language. It would take years to have a compiler that supports all modern C++ features AND keep it up to date.
>Exactly. It's bloated.
Is everything that has more features than C bloat?

I'm working on a road rash style game in SFML. Hadn't had any time to spend on it in the last year but I'll probably pick it up again now.
Please don't turn this into another hopeless C vs C++ thread.
Sorry for potato quality webm.

Attached: aa.webm (844x526, 2.33M)

Go back to your containment thread fucking retard

I released it and no one cared, oh well I already started working on the next one

I’d rather deal with this kind of code over having everything buried in 20 layers of classes and templates desu

>20 layers classes and templates desu
Maybe make a more realistic number?

Are there any good books that go through everything from design to implementation and feature various examples?

Discord faggotry

>Grouping data, functions that act up that data, and abstractions are bad because?
the grouping of functions and data is spurious and sometimes just serves as mental overhead. if you have a function C A::f(B), then it could equally validly be C B::f(A), but you have to actually pick one or the other. and if you encounter a situation where one was more appropriate than the other but the other was chosen, then it trips you up and more mental overhead is added. C f(A, B) is fine and straight to the point.

verbs are supposed to be the first-class citizens in programming anyway, not nouns. also fuck inheritance, fuck it hard.

looks more like Super Hang-On

I cannot help but notice that you have provided no points of criticism.

It's fine. The style is shit and not consistently adhered to, but the code is absolutely fine.

they're easier to make i assume. it's not like anyone would buy it and it seems like it would be a nice practice project.

You could try Game Coding Complete. It was pretty good but I got bored a bit in since it was a bit basic and I already had some programming experience.

>>classes
>Grouping data, functions that act up that data, and abstractions are bad because?
It's superfluous (bloat). You can already do OOP with structures:
typedef struct SomeObj SomeObj;
SomeObj *someObjNew(...);
void someObjDel(SomeObj *obj);
void SomeObjMethod(SomeObj *obj, ...);

>>RAII
Encourages small mallocs willy-nilly that mess up performance.
If you don't care about performance, use a script language, either embedded or standalone.
>>operator overloading
The operation overloading abuse is horrible (like streams), and truly beneficial applications are very limited.
Linear algebra is a good example, but calling a function instead is not a big deal.
>>function overloading
>This can be used in the wrong way, but it is helpful at times.
Little feature that along with other things results in function-name-mangling and destroys any thoughts for standard C++ ABI, which is much more important.
>>namespaces
>This prevents name collisions and help organize code.
Prefix the functions in the namespace with the namespace.
Like in GLFW library. Problem solved, no additional complexity introduced.
>>Is everything that has more features than C bloat?
No. As I said, "unnecessary features that introduce more complexity than it's worth" are bloat. Go and Lua are some nice little languages that have nice features C doesn't have, but Lua has limited domain because it's dynamic and for Go you have to have bindings to virtually every library, which isn't worth it for me.

Among these unnecessary features, we could add lambdas, the new syntaxes for "for" interators and many more.

Not the person you're responding to, but I had to interject because holy fuck!

>if you have a function C A::f(B), then it could equally validly be C B::f(A), but you have to actually pick one or the other.
First, of all, what is the 'C' suppose to be? Probably not C, because it doesn't have the scope resolution operator.

>and if you encounter a situation where one was more appropriate than the other but the other was chosen, then it trips you up and more mental overhead is added.
It's your fault for being stupid by not being able to differentiate between classes.

>f(A, B) is fine and straight to the point.
It's easy to read, yes. I will give you that.

>also fuck inheritance, fuck it hard.
Having a structured hierarchy between classes is good to see the relation from one another.

>which I really doubt.
Hyper-delusional C unt.

Why are you arguing with a ctard? You should know they have the stubbornness of a boomer.

That's you making the delusional statements ("will halve the code") without any actual proofs.

bad bait

Prove him wrong fuckboi

Both C and C++ are good programming languages, stop arguing.
To shut up, develop a game in your favourite language.
Get working.

Attached: 1521784225188.jpg (480x380, 14K)

>>Grouping data, functions that act up that data, and abstractions are bad because?
>It's superfluous (bloat). You can already do OOP with structures
A demonstratively complete lie. Simply grouping things under one name is not OOP. There is no access modifiers to allow encapsulation and abstractions.

>>>RAII
>Encourages small mallocs willy-nilly that mess up performance.
>If you don't care about performance, use a script language, either embedded or standalone.
So, meticulous and arduous tracking of heap allocated memory is good? Of course not. Having raw pointers is unsafe and error-prone.

>>>namespaces
>>This prevents name collisions and help organize code.
>Prefix the functions in the namespace with the namespace.
>Like in GLFW library. Problem solved, no additional complexity introduced.
This is a semblance of namespacing but really isn't.

C being the return type in that signature, you bellend. and the signature is obviously C++.

>It's your fault for being stupid by not being able to differentiate between classes.
i'll give you a facile example. imagine that we have a Car, but suddenly we come across across a method with this signature:

void Elephant::StopEngine(Car&);

when you're sticking functions inside classes, you're strictly categorizing them. but some functions defy clear categorization, and some are just put in the wrong category by people who touched the code long before you. at least if you just have freestanding functions like in C, you don't need to edit the signature (e.g. swap an argument of type A for an argument of type B) when you decide there's a more appropriate category for that function; you only need to change the function name

a constructor and a C init function are going to be roughly equal in length

Vomit-inducing.
>everything I cannot understand is bloat
>I hate having options that perfectly suit my needs and boost the workflow
>I much rather reinvent the wheel (more often than not suboptimally) as long as its MY implementation in MY code in MY language
>I love having publicly visible identifiers so that my tooltips display is about 4 screens big
Just. stop. Your language is outdated. Most things you listed are twisting and turning C into a ugly copycat of higher-level languages. Stop abusing C.

You're right, but it's a lot of fun!

>using structs is "twisting and turning C into a ugly copycat of higher-level languages"

>Likewise, only some select few clang and gcc contributors and people in the design committee know how C++ works.
>Compare the number of how many hobby C compilers (tcc, 8cc, vbcc, scc and many more) there are to how many hobby C++ compilers are there (0).

this isn't an argument and ultimately proves the supremacy of C++. good systems are rarely simple.

Not bad, but lacks story

I wonder when people will realize that it doesn't actually matter whether your language supports namespaces, because you're always lambasted for using "using" anyway. If you can't use "using" then, from the perspective of a programmer, there is absolutely no difference between "namespace_" and "namespace::" other than one having the enormously disgusting "::" operator following it.

HOLY SHIT STOP ARGUING C VS C++

Sticking functions in classes that do not have a direction relation with the class should not be put in their in the first places. They should be put in the appropriate class. I know what you're saying, but anything can be abused. If they can't write good code in their own languages, they should read up on how to do it.

>that disgusting switch statement
I threw up onto my keyboard

You're flying in the face of all common sense in engineering. Don't make me quote De-Exupery.

How would you do it?

>there is no access modifiers to allow encapsulation and abstractions
That's an opaque pointer, the only data that you can get/set is determined by the public API provided. Thus no need for private/public.
Also, shit like Python doesn't have any access modifiers but nobody argues that it's OOP.
>So, meticulous and arduous tracking of heap allocated memory is good?
This heavily discourages you from allocating many small blocks of memory and instead encourages you to minimize the heap usage and utilize the stack as much as possible.
>Having raw pointers is unsafe and error-prone.
C encourages you to have as few as possible.
If you don't want to care about them then drop the performance requirement and use a scripting language.

>This is a semblance of namespacing but really isn't.
Great! Let's introduce function-name mangling and fuck up all the hopes for cross-compiler-compatible ABI and let's instead prefix every library header with extern "C" instead! That's a great idea! Surely better than typing those couple additional characters!

I'm sorry! But it's just so much fun!

*direction=direct

like a normal human and not a retard.

But it's pretty like that

without the cascading indentation

i use unity3d

if you're a retard, maybe. You own me a new keyboard.

Where Ken Silverman at.

>typedef struct SomeObj SomeObj;
>typedef struct for a struct that is not opaque.
>uncoupled function names which do potentially buggy construction/destruction in a poorly typed language.

I'm honestly surprised you haven't whipped out some preprocessor macros yet. might as well, because at least macros could make your "c classes" look more correct.

laffing @ your life

i'm sure it'd be so much nicer to read as "AmuletsAndArmor::Effects::EffectDamage::ELECTRICITY", twat

What do you guys think?

Attached: Untitled.png (351x685, 24K)

i make $100k per month from android games alone
ask me. anythinh

you don't seem to know c

Fuck you

I was working on a cyberpunk roguelike but the project stalled due to not enough time. It's using a voxel engine written in C++, SDL, OpenGL. Pic is of a test of the procedurally generated road system. Would anyone contribute to it if I GPL'ed it?

Attached: 1515288192390.gif (512x512, 1.46M)

common sense is a human concept that is rarely "common" or "sensible."

please stop.

you clearly don't. you'd only typedef shit for things you are planning on exposing via an ABI and should not be trifled with.

>>there is no access modifiers to allow encapsulation and abstractions
>That's an opaque pointer, the only data that you can get/set is determined by the public API provided. Thus no need for private/public.

Anyway and everywhere can have access to the fields of any structs. This can cause loads of problems. Let me give a simple example:

If I have class and one of the member variables keeps track of the internal workings of class and allowing everyone outside the class access to it could cause malfunctioning in the class.

>>So, meticulous and arduous tracking of heap allocated memory is good?
>This heavily discourages you from allocating many small blocks of memory and instead encourages you to minimize the heap usage and utilize the stack as much as possible.
In C++, at least for me, I was encouraged to use the stack much as possible unless my object was too large or I was going to allocate several objects that wouldn't fit onto the stack.

>>Having raw pointers is unsafe and error-prone.
>C encourages you to have as few as possible.
And the average C code I see is littered with them.

>>This is a semblance of namespacing but really isn't.
>Great! Let's introduce function-name mangling and fuck up all the hopes for cross-compiler-compatible ABI and let's instead prefix every library header with extern "C" instead! That's a great idea! Surely better than typing those couple additional characters!
You got me on this one.

Completely unambiguous with zero overhead, reads like a novel.
:^)

This.... now THIS is the power.... of C
Whoa, C++ fags destroyed.

>you'd only typedef shit for things you are planning on exposing via an ABI and should not be trifled with.
what are you on about?

typedef struct A A;
struct A { ... };

void f(A*);

this is what everyone does to avoid writing "struct" or "enum" redundantly all over the place. that is it. i'm not sure what tree you're barking up, but it's probably the wrong one.

>preprocessor bullshit
C++ unfortunately has this, too.

Misguided loop unrolling is not a C thing.

and it's style haram and should not be done. typedefs are a stylistic choice which should let the C-tard know that this "type" is opaque, and for a good reason. likely because of architectural or abi reasons. using it as short hand is fucking retarded and clearly shows that you're a shitty "C koder"

you guys do know that non of the big companies use c/c++ anymore to develop games right?

SO STOP WORKING WITH INDIANS.

which for the most part you can avoid because C++ has a metaprogramming language that is also C++.

What do they use instead?

i do not care for your stylistic choices

>clearly shows that you're a shitty "C koder"
it's used in plan 9 and inferno, both co-written by the inventor of C; your argument is invalid