What Are You Working On August 2012

[T3hGamerDK]

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?

[Darwin226]

[QUOTE=Capsup;37230797]I'm using elements so that's why I put in vertices of 4, but get 2 triangles. Triangle 1 = element 0, 1, 2 and triangle 2 = element 1, 2, 3.
So I'm pretty sure it should be correct..?[/QUOTE]

Oh. Right. Didn't notice.

Yeah, there's nothing wrong with doing that.

[acpm]

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.

[img]http://img191.imageshack.us/img191/5281/halflife2sandbox.png[/img]
[t]http://img826.imageshack.us/img826/5370/halflife2sandboxc.png[/t]

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:

[lua]--========== 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()

[/lua]

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?

[T3hGamerDK]

[QUOTE=amcfaggot;37231267]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.

[img]http://img191.imageshack.us/img191/5281/halflife2sandbox.png[/img]
[t]http://img826.imageshack.us/img826/5370/halflife2sandboxc.png[/t]

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:

[lua]--========== 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()

[/lua]

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?[/QUOTE]

Just hard code the resolution, man.

[acpm]

[QUOTE=T3hGamerDK;37231305]Just hard code the resolution, man.[/QUOTE]

that doesn't have anything to do with my issue

my issue is that fonts you create in the scripted environment are destroyed when you change resolutions

so basically, this:
[img]http://img600.imageshack.us/img600/5281/halflife2sandbox.png[/img]

becomes this:
[img]http://img40.imageshack.us/img40/5281/halflife2sandbox.png[/img]

[danharibo]

[QUOTE=amcfaggot;37231347]that doesn't have anything to do with my issue

my issue is that fonts you create in the scripted environment are destroyed when you change resolutions[/QUOTE]

Wrap the fonts in some sort of proxy so that you don't use the font handles directly?

[acpm]

[QUOTE=danharibo;37231369]Wrap the fonts in some sort of proxy so that you don't use the font handles directly?[/QUOTE]

Yeah, that's what I'll have to do. My only concern is that the functions then become misleading to anyone who moves from Lua to C++.

Currently,
[lua]surface.DrawSetTextFont( HFont font )[/lua]
would be
[cpp]surface()->DrawSetTextFont( vgui::HFont hFont )[/cpp]

But wrapping it would mean you never actually use that type.

And you get something like:
[lua]surface.DrawSetTextFont( HFontContainer fontcontainer )[/lua]
to
[cpp]surface()->DrawSetTextFont( vgui::HFont hFont )[/cpp]

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.

[Jookia]

[QUOTE=amcfaggot;37231347]that doesn't have anything to do with my issue

my issue is that fonts you create in the scripted environment are destroyed when you change resolutions

so basically, this:
[img]http://img600.imageshack.us/img600/5281/halflife2sandbox.png[/img]

becomes this:
[img]http://img40.imageshack.us/img40/5281/halflife2sandbox.png[/img][/QUOTE]

I don't know anything about the source engine, but can't you just hook in to the resolution changing (or new graphics context) and have it rebuild the fonts? Cost obviously isn't an issue because you're changing the resolution in the source engine.

[acpm]

Do you think that's still acceptable, and I'd just tell people in documentation that HFontContainers allow for handle continuity?

[danharibo]

[QUOTE=amcfaggot;37231457]Yeah, that's what I'll have to do. My only concern is that the functions then become misleading to anyone who moves from Lua to C++.

Currently,
[lua]surface.DrawSetTextFont( HFont font )[/lua]
would be
[cpp]surface()->DrawSetTextFont( vgui::HFont hFont )[/cpp]

But wrapping it would mean you never actually use that type.

And you get something like:
[lua]surface.DrawSetTextFont( HFontContainer fontcontainer )[/lua]
to
[cpp]surface()->DrawSetTextFont( vgui::HFont hFont )[/cpp]

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.[/QUOTE]

Well just do what makes the most sense, you have to take into account that Lua isn't really C++, you can't always apply the same ideas in the same way.

[acpm]

[QUOTE=Jookia;37231480]I don't know anything about the source engine, but can't you just hook in to the resolution changing (or new graphics context) and have it rebuild the fonts? Cost obviously isn't an issue because you're changing the resolution in the source engine.[/QUOTE]

Yep, that's the plan. My only problem here is concern for semantics.

[editline]14th August 2012[/editline]

[QUOTE=danharibo;37231487]Well just do what makes the most sense, you have to take into account that Lua isn't really C++, you can't always apply the same ideas in the same way.[/QUOTE]

Yeah, you're right. Well I guess that answers that.

[Jookia]

You could always write it in a gotchas.txt file for Lua users, but Lua users shouldn't be trying to C++.

[acpm]

[QUOTE=Jookia;37231550]You could always write it in a gotchas.txt file for Lua users, but Lua users shouldn't be trying to C++.[/QUOTE]

I think I'll just stick to putting it down as a note in the documentation, but yeah. Lua users shouldn't be trying to face the same problems C++ users do, for sure, but the reasoning for the API being so similar is to provide a better sense of what is being used internally, while still having ease of development. It is scripting after all.

[editline]14th August 2012[/editline]

Thanks for your feedback guys.

[Maurice]

Update of Gamescom stuff:

[img]http://i.imgur.com/LHWvL.jpg[/img]

We get chairs tomorrow morning.
(By the way we couldn't find the Valve booth..)

[Gran PC]

What's that in front of the computer with Not Tetris running?

[Maurice]

NES controller.

[Richy13]

Why a driving wheel for pacman?

[Gran PC]

[QUOTE=Maurice;37232075]NES controller.[/QUOTE]

That's awesome.

[Maurice]

[QUOTE=Richy19;37232077]Why a driving wheel for pacman?[/QUOTE]

Because we can.
(You rotate the screen and pacman tumbles about in the game.)

[acpm]

[QUOTE=Maurice;37232003](By the way we couldn't find the Valve booth..)[/QUOTE]

its still in development

[editline]14th August 2012[/editline]

[QUOTE=Maurice;37232109]Because we can.
(You rotate the screen and pacman tumbles about in the game.)[/QUOTE]

i was expecting pac-man drive-bys

this is okay too

[Cesar Augusto]

[QUOTE=Maurice;37232003]Update of Gamescom stuff:

[img]http://i.imgur.com/LHWvL.jpg[/img]

We get chairs tomorrow morning.
(By the way we couldn't find the Valve booth..)[/QUOTE]

Awesome

[Richy13]

[QUOTE=Maurice;37232003]Update of Gamescom stuff:

[img]http://i.imgur.com/LHWvL.jpg[/img]

We get chairs tomorrow morning.
(By the way we couldn't find the Valve booth..)[/QUOTE]

Did gamescon/anyone contact you about going there? or did you just decide to go?

[Mr. Bleak]

Finally decided after a few months of frustration to give learning Python another crack.

The coolest bit so far is finding a use for my TV while I'm on my PC. Now I can have the help guides and tutorials display on my TV with powershell, Notepad++, and the python shell on my laptop screen. Pretty neato.

[Map in a box]

[QUOTE=Richy19;37232399]Did gamescon/anyone contact you about going there? or did you just decide to go?[/QUOTE]

I think it's more you contacting gamescon

[Richy13]

Since when does steam allow for game maker games?

[acpm]

[QUOTE=Richy19;37232466]Since when does steam allow for game maker games?[/QUOTE]

I don't think Valve cares entirely about what the software used to develop the game is. They always seem far more interested in seeing an actually fun game.

[Richy13]

I remember not so long ago they said that games made with game making tools werent allowed

[It's crispy]

[QUOTE=Richy19;37232534]I remember not so long ago they said that games made with game making tools werent allowed[/QUOTE]

They have never said that

[Map in a box]

Unless of course you are put on there for some weird reason such as for this:
[url]http://www.valvetime.net/attachments/half-life3reveal-png.23733/[/url]
Valve didn't put that on there and wanted it off.

[editline]14th August 2012[/editline]

And for those who don't know, IIRC the player physics in Source are mostly hardcoded to give it a nice feeling.

[slime73]

[QUOTE=Richy19;37232534]I remember not so long ago they said that games made with game making tools werent allowed[/QUOTE]
Games which can't be run using an exe file aren't allowed, that's pretty much it.