I don't think resolving those issues aids in IntelliSense working, but they are things that need to be taken care of in the first place.
I said that my friend has it compiling 100% and we're both using same source/project file. Alien Swarm compiles (or should) out-of-box.
I wrote an article about my old physics platformer game.
It covers the creation of my custom physics engine, where it failed, and how it survives today.
Check it out, you may find it interesting :)
Have my adopted babbeis
Read that entire article, was a fun read
Anxious for part 2!
I think anyone wanting to make a platformer has run into that Box2D issue. They should really just fix it instead of making people use chains and stuff.
That's exactly what I try to develop right now!
I started to create/invent a game, too. And I'm inventing a Collision/Physics-System just like you.
Pictures will follow. ;)
Although, I wonder what Source uses to keep the player controls tight while also running a physics engine...
I'd be more than happy to provide you my entire source, if you'd like Darwin. I just really want to get this to work, but after 2 days of hair pulling, I just don't have much hair left.
You've inspired me to do some more work on my platformer, as well.
And thanks alot for the help so far. :)
You should be able to come somewhat close with separate directional damping and friction relative to the (intended) movement direction and by adjusting damping based on player input.
In the part where you populate the vertices vector you use XZ, X+1Z, XZ+1 and X+1Z+1 but the normals you use for each of those are not attached to those points on the map in any way.
Imagine this gird
You are pushing in the coordinates of ABG and H but normals of ABC and D. Then for the next quad you use BCHI but the normals of BCDE.Code:ABCDEF GHIJKL
That's my understanding of your code anyways.
Also, what I found strange is that you construct quads in the vertices vector but later on you render as triangles. Thought I admit, I didn't look through the whole thing if you do some extra transformations to it later, you did load that quad filled vector into the buffer.
Hey everyone, I'm glad you found my first article about collisions interesting. I've finished writing the second part, that you can find here:
It explains how collision detection and resolution is done in my simple 2d collision engine. It is full of code and easy-to-understand diagrams, along with some .gifs of my older projects.
It also contains links to my GitHub page, where all the source code is freely available.
Check it out! :D
As for the quads thing, you're right. You should render triangles instead of quads because quads are deprecated, the thing is, when you tell GPU to render triangles it expects sets of 3 vertices, when you tell it to render quads it expects sets of 4 vertices. If you make your buffer contain quads (4 vertices) and render triangles from that then the last vertex in the first set will be the first vertex of the next set and... well.
The thing is, it appears to be working just fine so I don't know about that...
So I'm pretty sure it should be correct..?
I've just started out a bit with Perl 6 using Rakudo. Anything bad I should know about the performance before getting on with it?
So, I've got this thing that I want to resolve, but I'm not sure how I want to do it yet. The Source engine Lua API in HL2:SB lets you handle your own fonts.
That's great, but it means you have to recreate them manually in OnScreenSizeChanged when... you guessed it - the screen size changes - because they're scripted in, and not loaded through a scheme. All of the fonts invalidate at that point, and need to be recreated. On top of it, since they're scripted, you have to replace the font handles.
So a unit test of this, without font reloading, looks like:
--========== Copyleft © 2012, Team Sandbox, Some rights reserved. ===========-- -- -- Purpose: Tests the usage of HFont with surface library functions. -- --===========================================================================-- if ( not bit ) then require( "bit" ) end local bor = bit.bor local vgui = require( "vgui" ) local Frame = vgui.Frame local Panel = vgui.Panel surface.AddCustomFontFile( "gamemodes\\sandbox\\content\\resource\\DINLi.ttf" ) local hTestFont = surface.CreateFont() surface.SetFontGlyphSet( hTestFont, "DIN-Light", 36, 0, 0, 0, bit.bor( 0x010, 0x100, 0x400 ) ) local strTextSample = "The five boxing wizards jump quickly." g_hFontTestFrame = Frame() g_hFontTestFrame:SetBounds( 0, 0, 408, 120 ); g_hFontTestFrame:SetSizeable( false ) g_hFontTestFrame:SetTitle( "Font Test", true ) g_hFontTestFrame:SetVisible( true ) g_hFontTestFrame.m_hFontSamples = Panel( g_hFontTestFrame, "FontSamples" ) g_hFontTestFrame.m_hFontSamples:SetProportional( true ) local iFontWide, iFontTall = surface.GetTextSize( hTestFont, strTextSample ) g_hFontTestFrame.m_hFontSamples:SetPos( 0, 120/2 - iFontTall/2 + 4 ) g_hFontTestFrame.m_hFontSamples:SetSize( 408, iFontTall + 8 ) function g_hFontTestFrame.m_hFontSamples:Paint() surface.DrawSetTextFont( hTestFont ) surface.DrawPrintText( strTextSample ) end g_hFontTestFrame:DoModal()
It doesn't really get any lower than this. The bindings are direct, and no utility functions are made. So I was thinking, "Well okay, Garry's Mod uses name lookups instead of handles, but you lose some execution speed doing that." So I don't think I want to ditch the handles. But how do I make the handles work through screen size changes?
Well, in Lua, I can use some sort of HFont container instead and write a fontmanager module, or internally, I can make a font manager to do the same thing.
I have a problem with these two methods though, but there isn't any other way for me to do this.
Most, if not every last binding, is a low-level API one. I haven't implemented utilities yet because I haven't thought much on the issue. I'll get there when I do. Anyway, if I end up containing the HFont data, I have to write in some sort of set of overloads for the current surface functions to accept the new containers, but the name of the functions would most likely stay the same, so they no longer accurately represent what is going on in Source.
I could no longer say they were HFonts being used in the relevant functions, but more like... handles for the font handles...
Right now I'm trying to think of the best way to tackle this, because this is one of my only projects where I don't really iterate a lot over what is completed. I do the best I can the first time around, and rarely have had to come back to fix something. I do this mainly because I have too many things I'd like to touch on with the project, so it's a better time investment for me to take a little longer so it's done right the first time.
Maybe one of you guys has a better idea?
my issue is that fonts you create in the scripted environment are destroyed when you change resolutions
so basically, this:
would besurface.DrawSetTextFont( HFont font )
surface()->DrawSetTextFont( vgui::HFont hFont )
But wrapping it would mean you never actually use that type.
And you get something like:
tosurface.DrawSetTextFont( HFontContainer fontcontainer )
surface()->DrawSetTextFont( vgui::HFont hFont )
I think I'm being picky for the sake of semantics. But I dunno, it's my project, and that was one of the paradigms - to keep as close as possible to the Source SDK.
Do you think that's still acceptable, and I'd just tell people in documentation that HFontContainers allow for handle continuity?
You could always write it in a gotchas.txt file for Lua users, but Lua users shouldn't be trying to C++.
Thanks for your feedback guys.
Update of Gamescom stuff:
We get chairs tomorrow morning.
(By the way we couldn't find the Valve booth..)
What's that in front of the computer with Not Tetris running?
Why a driving wheel for pacman?