Commented 4 years ago2020-11-24 21:04:10 UTC
in vault item: awp_tokyo_v2Comment #103086
In what way? Wallbanging or would the map be darker overall? If wallbanging is the issue, then you can set ZHLT lightflags to "Opaque + concave fix", so that func_wall is gonna cast the shadows and all.
Commented 4 years ago2020-11-20 10:26:01 UTC
in journal: #8888Comment #103075
Not entirely alone. I found my comfort in an Internet relationship with a Hungarian girl, who I'm hoping to meet one day once I've a job and a car. Hungary's pretty damn close, unlike the countries of all my previous relationship partners (mainly the USA and the UK).
It kinda sucks that I've been starved of physical affection for years. Certainly, there are many people out there who are the same. Haven't had a hug, haven't kissed anyone, haven't been kissed... but alas. If I've gone through this year like that, I'll go through the next 5 ones just like so.
But I know I'll get hugs one day
This comment was made on an article that has been deleted.
This comment was made on an article that has been deleted.
Commented 4 years ago2020-11-01 18:47:14 UTC
in journal: GoldSRC + Godot = ???Comment #103001
The truth is, I don't even have to use VISAREA brushes. I can quite simply mark everything "between" VISPORTAL brushes as a visarea, basically what idTech 4 does. The only issue with that is the consequential existence of leaks, whereas with the system described in the journal, leaks don't have to exist. If I gain any greater understanding of VHLT, I might as well implement this idea in HL. xD
Anyway, I moved the project from Godot back to idTech 3. A month's worth of work has been undone, for the greater good.
In a nutshell, I underestimated the required amount of work to do the new entity system properly. The plan was to integrate a common entity interface between the game DLL, client DLL and the server part of the engine. But, since I need to start making a game in January or February, and finish a demo by May (for a local gamedev competition), I decided to drastically decrease the needed work (and time) by keeping the entity interface only in the game DLL.
So what this means is, the engine and client only know about something called sharedEntity_t, which is kinda like GoldSRC's edict_t and entvars_t, while the game DLL will have a bunch of different entity classes.
It's not a big deal. I can still implement entity components the way I imagined, and I can get rid of the old game entity (gentity_t) system.
Commented 4 years ago2020-10-20 12:55:03 UTC
in vault item: 2020 PracticeComment #102981
Given these screenshots, I'd say it's a pretty solid work in progress. It's always good to see someone learning by basically trying out everything the game offers you (in terms of entities), like I did when I started out. Definitely gives a very solid understanding of things and whatnot.
So with all that said, I'm looking forward to updates and stuff. ^^
Commented 4 years ago2020-10-17 19:34:52 UTC
in journal: Unity Game Dev.Comment #102962
Well, you could freely contact me if you want C# mentoring in general, I'd say I'm good enough at it lol.
Cameras are, really, just points in space with some extra properties (FOV, far clipping plane, near clipping plane). In the case of 2D, they just have an XY position, a zoom factor, and a single angle. So, if you'd like the camera to follow Spike, you'd do something like this:
// Somewhere in some Initialize method: (assuming your player entity contains a Camera component and a Player component of some sorts)
playerComponent = GetParent().GetComponent<PlayerComponent>();
// Somewhere in some OnUpdate method:
cameraPosition = playerComponent.GetTransform().GetPosition();
So what's gonna happen is, the camera grabs a reference to your current player, and tracks the position. So wherever the player moves to, the camera follows along. The real fun happens when you start experimenting.
Commented 4 years ago2020-10-16 19:52:54 UTC
in journal: Unity Game Dev.Comment #102959
Why did you disable embedding? <w< But anyway, that looks cute.
My only complaint would be the very noticeable usage of FL Slayer in that song, assuming you made the song. I'd recommend getting some clean electric guitar samples (actually, FL Slayer without any post-processing will do) and Guitar Rig 5. Guitar Rig 5's demo has enough functionality to distort a guitar sound real good.
Commented 4 years ago2020-10-15 18:16:36 UTC
in journal: Unity Game Dev.Comment #102957
Oh right, I was talking about 3D when I mentioned map geometry, lol.
The reason behind going straight through geometry is that triangles are infinitely thin. The physics engine isn't aware of the "volume" of the mesh, so of course it's gonna screw up the collision at high velocities. You can think of it like treating each triangle as a separate physics object, completely disregarding the big picture. If it worked flawlessly, taking into account the volume of a concave mesh, it'd be very slow. xD
Generally, what people do in that situation is make a dedicated group of convex collision meshes (e.g. a table would have 1 wide rectangular prism, and 4 thin cylinders for collision), in which case it's easier for the physics engine to process it and it's aware of the volume. Dunno how that one works in Unity, but at least you can use a bunch of box & cylinder colliders to approximate the mesh.
Commented 4 years ago2020-10-15 17:00:20 UTC
in journal: Unity Game Dev.Comment #102955
While I don't have any significant experience with Unity (not to say I didn't try it out), I can tell you about modern engines in general:
map geometry is all made of models; although some engines like Godot and Unity have decent CSG plugins
as you've already witnessed, you start from scratch; you must invent your own movement physics or use a physics engine, you must invent your own system for this and that, specific to your game, basically everything is from scratch and all the engine does is handle the lower-level stuff like allocating memory for entities & components, render stuff and stuff like that
as you might've also noticed, asset importing is much easier; you can just drag'n'drop stuff, either into the editor's asset explorer or into some folder in your project
I think you made a nice choice if you haven't messed with programming before. C# is easier and forgiving compared to C++. At some point, you might also wanna try out Godot which also supports C# (alternatively, it offers its own scripting language GDScript), and there's a TrenchBroom plugin for it to directly import TrenchBroom maps or something.
I, personally, occasionally experiment with Unigine 2 and CryEngine 5, which are big behemoths (but still perform better and run better than UE4 AHAHAHA), and otherwise I work with idTech 3 (Quake 3 engine) and idTech 4 (Doom 3 engine), with which I've done some more significant progress. Though, I'm also planning to do some stuff in Unity and Godot.
I think it's a combination of both, Captain P. A combination of space saving and being easy to parse by the compilers. Also, normal + offset would increase loading times in a map editor while opening a .map file, I imagine. ^^
Commented 4 years ago2020-07-30 13:58:01 UTC
in journal: More of this...Comment #102824
This is one hell of an effort to put into a TWHL journal. I legit thought of downloading the map but I didn't have Minecraft installed. My hat's off to you. Happy birthday!
Commented 4 years ago2020-06-23 12:57:21 UTC
in journal: Bye Internet ExplorerComment #102770
Thing is, nowadays most people want things to look beautiful, and the technology behind that is way below optimal in terms of performance. Also, JavaScript. A language that got hacked together in two weeks and had nothing to do with Java itself, but was named like that because it'd get popular that way. Curse JavaScript. It is why I avoid web development and will always avoid it, until the day when I can do both the frontend and backend entirely in something like C.
And the thing is, then you got a wave of developers thinking "oh, hardware is getting better and better, we don't have to worry about making things run that well on current hardware", but also developers who are there for the money, which is basically the same thing as you've just said.
In the real world, the average user of a website cares if it works and it's a plus if it looks good. In March, when some company launched an online school platform in Bosnia, the only thing our teachers would say, whenever the website went down, or whenever there was an error, is "it doesn't work", "it's broken" and such. They didn't know how much RAM their browser was occupying when that website was loaded and didn't care, because the only other program they had opened at the time was probably Zoom or a browser tab in Facebook.
I think most of them (web developers and browser developers) will never care about people like us.
Commented 4 years ago2020-06-22 22:21:20 UTC
in journal: Bye Internet ExplorerComment #102768
"it takes a few hundred MB ram to display a simple html page. What is this madness?"
There's an engine that processes HTML and CSS code. Then there's an engine that executes JavaScript code. Then there's cached data which is loaded into memory for faster access. Then there are all the libraries and APIs that a browser will use. I wouldn't be surprised.
If only one of those were missing, your websites would either reload completely every time you visit them, or they would look like a badly formatted Word document, or they would lag a lot, or they would look like a plain text file. The crazy ecosystem of web development brought up these standards so browsers have to support them. And that carries a price to pay.
The fact that bad web developers exist also doesn't make things any better. Penguinboy is, of course, a big exception otherwise TWHL4 (and TWHL3) wouldn't exist in any good shape.
"Back in the day the entire OS would run on 256MB just fine and youtube on top of that."
Way back in the day, an entire OS and browser could run on 64MB and YouTube didn't exist. A decade before that, you could connect to a mainframe with your terminal which had 64KB of RAM. Where's your point?
Back in the day, I had a 2007 laptop with just 2GB of RAM and it ran Firefox fine. This is 2020 and frankly, a few hundred MB isn't much. Save up some money, upgrade your system, what else can I tell you? Or, program your own browser and make it the most lightweight thing ever. All webpages are gonna look like they're from 1995, lmao.
Commented 4 years ago2020-06-22 16:49:52 UTC
in journal: Bye Internet ExplorerComment #102765
On Chrome, all downloads seem to fail for me, lol. I used Vivaldi for a while, which was cool but then YouTube broke while it worked on other browsers fine. Unacceptable. Downloads also stopped showing after a while and I had to clear my download list. Never used Edge, never will. Same goes for Opera, Safari etc. Privacy is something I don't really care about. I'm 100% fine with companies knowing everything about me, so I ain't gonna judge any browser by privacy-related things.
Firefox is pretty decent. It has served me for YEARS, and it will. I don't have to update it, it'll work just fine. I don't see how it's garbage, I don't see how it's useless (it displays webpages so it clearly has a use), and I don't see how it's bloatware.
So yeah, that statement of yours is mostly invalid.
Guess how old he was when he wrote the one about vectors. 14, you can find it in the Web Archive copy of the "Vectors: An introduction" page, in the comments
That's not the point though. It was a sort of a revolutionary time for HL modding IMO. People were discovering vertex and pixel shaders, some were already integrating Cg into their Half-Life mods, people were learning about new graphics techniques and concepts which new games were about to take advantage of (e.g. normal mapping), some folks were experimenting with integrating physics engines into HL, Paranoia started development, HL SDK 2.3 got released with a certain change that I really like about it, and so on.
His articles are a living documentation of that time period and every time I read "Vertex and pixel shaders", I'd imagine how it used to be back in 2003 when a lot of that was an alien concept among us modders. Now, a lot of people know about shaders and physics engines, for example. In fact, the Blinn-Phong shading model is old news by now. We got Physically Based Rendering.
The early 2000s also saw the development of vehicles for HL mods, such as this beautiful example:
But why didn't we see any of that? Why didn't we get to play any of that, even? God knows. And that's what I wanna change.
I want to bring back some golden times, to carry one of the torches of HL modding. Don't get me wrong, HL modding is amazing, especially in this day and age where we can compile maps in minutes and people are still interested. But, I got a vision that HL modding can be far better than it is now. Which is why I started the Advanced Development Mod project.
"I wish I had done as much as you do at your age."
There are countless things I wish I had done earlier too, to be honest. 5 years ago, I made the mistake of starting to make a total conversion mod instead of deciding to learn the skills first and whatnot. Though, I gotta say, it was a good mistake. I wouldn't be doing these projects otherwise. I wish I started doing C++ stuff at least 2 years earlier, you know. But, when you think about it, maybe it's a good thing that I started it 2 years ago than 4 years ago. Cuz' those 2 years in between helped me improve my mapping skills, as well as texturing and music skills.
I think everything has its reason, even though when we think something should've been better done earlier. Sometimes, it's true, we SHOULD have done some things earlier, but at other times, maybe it was for the better, because something else happened and it was a good thing. You get what I'm trying to say.
"the world won't stop and knowledge keeps passing on."
Always gotta carry that torch. It's one of the reasons why I write tutorials.
Commented 4 years ago2020-03-21 09:56:11 UTC
in journal: CoronavirusComment #102601
Doing pretty well over here. I'm having "online" classes (where teachers just send us PDFs and Word documents of lessons), and washing my hands slightly more frequently.
Since I'm in a village and pretty much nobody is visiting us, the chance of getting infected is a bit lower here, but despite that, I'm still a worried for my grandma and my parents. Especially my grandma.
And since I get to stay at home more, I decided to use the bike a bit more often.
warms the beacon
If wallbanging is the issue, then you can set ZHLT lightflags to "Opaque + concave fix", so that func_wall is gonna cast the shadows and all.
I found my comfort in an Internet relationship with a Hungarian girl, who I'm hoping to meet one day once I've a job and a car. Hungary's pretty damn close, unlike the countries of all my previous relationship partners (mainly the USA and the UK).
It kinda sucks that I've been starved of physical affection for years. Certainly, there are many people out there who are the same. Haven't had a hug, haven't kissed anyone, haven't been kissed... but alas. If I've gone through this year like that, I'll go through the next 5 ones just like so.
VISAREA
brushes. I can quite simply mark everything "between"VISPORTAL
brushes as a visarea, basically what idTech 4 does. The only issue with that is the consequential existence of leaks, whereas with the system described in the journal, leaks don't have to exist.If I gain any greater understanding of VHLT, I might as well implement this idea in HL. xD
Anyway, I moved the project from Godot back to idTech 3. A month's worth of work has been undone, for the greater good.
So what this means is, the engine and client only know about something called
sharedEntity_t
, which is kinda like GoldSRC'sedict_t
andentvars_t
, while the game DLL will have a bunch of different entity classes.It's not a big deal. I can still implement entity components the way I imagined, and I can get rid of the old game entity (
gentity_t
) system.It's always good to see someone learning by basically trying out everything the game offers you (in terms of entities), like I did when I started out. Definitely gives a very solid understanding of things and whatnot.
So with all that said, I'm looking forward to updates and stuff. ^^
Cameras are, really, just points in space with some extra properties (FOV, far clipping plane, near clipping plane). In the case of 2D, they just have an XY position, a zoom factor, and a single angle. So, if you'd like the camera to follow Spike, you'd do something like this: So what's gonna happen is, the camera grabs a reference to your current player, and tracks the position. So wherever the player moves to, the camera follows along. The real fun happens when you start experimenting. This will make the camera never move up'n'down, only left-right following the player, just like Super Mario Bros. for the NES. xD
Keep in mind that I got no Unity scripting experience so this code won't apply, it's more like pseudocode to get the idea across.
But anyway, that looks cute.
My only complaint would be the very noticeable usage of FL Slayer in that song, assuming you made the song. I'd recommend getting some clean electric guitar samples (actually, FL Slayer without any post-processing will do) and Guitar Rig 5. Guitar Rig 5's demo has enough functionality to distort a guitar sound real good.
The reason behind going straight through geometry is that triangles are infinitely thin. The physics engine isn't aware of the "volume" of the mesh, so of course it's gonna screw up the collision at high velocities. You can think of it like treating each triangle as a separate physics object, completely disregarding the big picture. If it worked flawlessly, taking into account the volume of a concave mesh, it'd be very slow. xD
Generally, what people do in that situation is make a dedicated group of convex collision meshes (e.g. a table would have 1 wide rectangular prism, and 4 thin cylinders for collision), in which case it's easier for the physics engine to process it and it's aware of the volume. Dunno how that one works in Unity, but at least you can use a bunch of box & cylinder colliders to approximate the mesh.
- map geometry is all made of models; although some engines like Godot and Unity have decent CSG plugins
- as you've already witnessed, you start from scratch; you must invent your own movement physics or use a physics engine, you must invent your own system for this and that, specific to your game, basically everything is from scratch and all the engine does is handle the lower-level stuff like allocating memory for entities & components, render stuff and stuff like that
- as you might've also noticed, asset importing is much easier; you can just drag'n'drop stuff, either into the editor's asset explorer or into some folder in your project
I think you made a nice choice if you haven't messed with programming before. C# is easier and forgiving compared to C++.At some point, you might also wanna try out Godot which also supports C# (alternatively, it offers its own scripting language GDScript), and there's a TrenchBroom plugin for it to directly import TrenchBroom maps or something.
I, personally, occasionally experiment with Unigine 2 and CryEngine 5, which are big behemoths (but still perform better and run better than UE4 AHAHAHA), and otherwise I work with idTech 3 (Quake 3 engine) and idTech 4 (Doom 3 engine), with which I've done some more significant progress.
Though, I'm also planning to do some stuff in Unity and Godot.
Send a private message to Captain P. about the map, he's still online from time to time ^w^
Happy 25th birthday lol
You know, for bragging rights.
I turned 18 in February.
And don't worry, your English is pretty good. In fact, you will learn even more of it, if you talk more on the forums.
Also, JavaScript. A language that got hacked together in two weeks and had nothing to do with Java itself, but was named like that because it'd get popular that way. Curse JavaScript. It is why I avoid web development and will always avoid it, until the day when I can do both the frontend and backend entirely in something like C.
And the thing is, then you got a wave of developers thinking "oh, hardware is getting better and better, we don't have to worry about making things run that well on current hardware", but also developers who are there for the money, which is basically the same thing as you've just said.
In the real world, the average user of a website cares if it works and it's a plus if it looks good. In March, when some company launched an online school platform in Bosnia, the only thing our teachers would say, whenever the website went down, or whenever there was an error, is "it doesn't work", "it's broken" and such. They didn't know how much RAM their browser was occupying when that website was loaded and didn't care, because the only other program they had opened at the time was probably Zoom or a browser tab in Facebook.
I think most of them (web developers and browser developers) will never care about people like us.
If only one of those were missing, your websites would either reload completely every time you visit them, or they would look like a badly formatted Word document, or they would lag a lot, or they would look like a plain text file. The crazy ecosystem of web development brought up these standards so browsers have to support them. And that carries a price to pay.
The fact that bad web developers exist also doesn't make things any better. Penguinboy is, of course, a big exception otherwise TWHL4 (and TWHL3) wouldn't exist in any good shape. Way back in the day, an entire OS and browser could run on 64MB and YouTube didn't exist. A decade before that, you could connect to a mainframe with your terminal which had 64KB of RAM. Where's your point?
Back in the day, I had a 2007 laptop with just 2GB of RAM and it ran Firefox fine. This is 2020 and frankly, a few hundred MB isn't much. Save up some money, upgrade your system, what else can I tell you? Or, program your own browser and make it the most lightweight thing ever. All webpages are gonna look like they're from 1995, lmao.
I used Vivaldi for a while, which was cool but then YouTube broke while it worked on other browsers fine. Unacceptable. Downloads also stopped showing after a while and I had to clear my download list.
Never used Edge, never will. Same goes for Opera, Safari etc.
Privacy is something I don't really care about. I'm 100% fine with companies knowing everything about me, so I ain't gonna judge any browser by privacy-related things.
Firefox is pretty decent. It has served me for YEARS, and it will.
I don't have to update it, it'll work just fine. I don't see how it's garbage, I don't see how it's useless (it displays webpages so it clearly has a use), and I don't see how it's bloatware.
So yeah, that statement of yours is mostly invalid.
Quest unlocked: Real Life
He used to write some really nice articles on VERC before that place went down.
Bump mapping in Half-Life (2004)
Vertex and pixel shaders (2003)
Vectors: An introduction (2002)
Guess how old he was when he wrote the one about vectors.
14, you can find it in the Web Archive copy of the "Vectors: An introduction" page, in the comments
That's not the point though. It was a sort of a revolutionary time for HL modding IMO. People were discovering vertex and pixel shaders, some were already integrating Cg into their Half-Life mods, people were learning about new graphics techniques and concepts which new games were about to take advantage of (e.g. normal mapping), some folks were experimenting with integrating physics engines into HL, Paranoia started development, HL SDK 2.3 got released with a certain change that I really like about it, and so on.
His articles are a living documentation of that time period and every time I read "Vertex and pixel shaders", I'd imagine how it used to be back in 2003 when a lot of that was an alien concept among us modders. Now, a lot of people know about shaders and physics engines, for example. In fact, the Blinn-Phong shading model is old news by now. We got Physically Based Rendering.
The early 2000s also saw the development of vehicles for HL mods, such as this beautiful example:
And that's what I wanna change.
I want to bring back some golden times, to carry one of the torches of HL modding. Don't get me wrong, HL modding is amazing, especially in this day and age where we can compile maps in minutes and people are still interested. But, I got a vision that HL modding can be far better than it is now. Which is why I started the Advanced Development Mod project. There are countless things I wish I had done earlier too, to be honest.
5 years ago, I made the mistake of starting to make a total conversion mod instead of deciding to learn the skills first and whatnot. Though, I gotta say, it was a good mistake. I wouldn't be doing these projects otherwise.
I wish I started doing C++ stuff at least 2 years earlier, you know. But, when you think about it, maybe it's a good thing that I started it 2 years ago than 4 years ago. Cuz' those 2 years in between helped me improve my mapping skills, as well as texturing and music skills.
I think everything has its reason, even though when we think something should've been better done earlier. Sometimes, it's true, we SHOULD have done some things earlier, but at other times, maybe it was for the better, because something else happened and it was a good thing.
You get what I'm trying to say. Always gotta carry that torch. It's one of the reasons why I write tutorials.
I'm having "online" classes (where teachers just send us PDFs and Word documents of lessons), and washing my hands slightly more frequently.
Since I'm in a village and pretty much nobody is visiting us, the chance of getting infected is a bit lower here, but despite that, I'm still a worried for my grandma and my parents. Especially my grandma.
And since I get to stay at home more, I decided to use the bike a bit more often.
I remember when TJB once surprised me for my birthday, roughly a month after said birthday. So better late than never!
BTW a small update on the situation: I've been forgiven and I am happier than ever.
So good that it crashed my game when ribcage whacked me with a crowbar. Amazing.