Category: BooBoo

Here is show CoinHunt running at 16x speed. That’s 16x as much code being run per frame. It knocks the framerate from 480 to 380 FPS. So it goes to show you could run 64x+ as much code as CoinHunt on a low end PC. CoinHunt’s main loop (run function) is 1266 lines including many function calls called in loops. So it’s probably 2000+. So you could run 128,000 lines of BooBoo per frame in your run function on a low end PC.

EDIT: Running CoinHunt with +ops shows my guess was way off. I get 15,750 lines per frame (stock speed). So crunching the numbers, it’s a little over a million lines per frame you could do on this PC at 60 FPS.

EDIT2: It doesn’t scale that way though. It seems there is a lot more code in the draw function than I thought. My original estimate wasn’t bad… but it’s actually about 3125 not 2000. So it seems like 200,000 lines of run function is the closer estimate. This draw function has tens of thousands of lines per frame just drawing stars.

EDIT3: This includes all code in loops (each time it’s run counts as 1) and function calls. I think 200,000 “big instructions” per frame is a perfect level of challenge for a single or small team of developers, which is what BooBoo is designed for. Keep in mind this measurement is based on “somewhat average lines of code”.

If you buy it on Humble, you get a redistribution license and the Linux version.

EDIT: The Linux version is free to try now too

Some of the changes were sparked by thoughts about how I’m going to create save states. I came up with the idea of something like this:

"entities": [
    { "chest", [ x, y, opened... ] },
    { "person", [ x, y, ... ] },...
]

You would read the name and use toptr something like:

= name (json_get_string json "entities>[0]")
= name (string_format "create_%" name)
var ptr
= ptr (toptr name)
; create a vector from the array after "chest" /etc, which can be fully automated
var entity
call_result entity *ptr vec
vector_add entities entity

Now the load code doesn’t need to know about the types. Typically you see:

if (type == chest) {
}
if (type == person) {
}
; a million others

By the way, if you use this trick, it won’t work if you obfuscate your code. I can allow it though through a command line switch to list your create_ functions/etc.

• Improvements to docs
• Add json_add_array and json_add_hash
• Add json_typeof, json_size and json_create
• Add get_savedgames_path (CLI also)

• Support all fully supported Steam language in get_system_language
• Keep user scissor/viewport after resize
• Add get_ function for graphics settings
• Rename black_bar to letterbox
• get_args now works in BooBooCLI
• Separate fore/back colours (text_fore, text_back) text colours
• Add (widget_get_padding_*)
• Add sort and unique
• added convert_model to tools

It converts ascii .x models to custom .nsm (binary Nooskewl models). In my test the zeus.x model loaded 1000 times at 23.17 seconds and .nsm version loaded 1000 at 2.9 seconds, and it’s also half the size.

• Standalone docs
• draw_3d named draw_vertex_buffer
• draw_3d/draw_model/draw_billboard no longer mess with the depth buffer
• file_read_line now includes newline, add file_read/write_byte
• Add string_set_char_at
• vector_clear and map_clear can clear multiple containers

Can draw in 2d also. Actually the difference is draw_3d (removed) manages the depth buffer but draw_vertex_buffer doesn’t. So if you’re drawing 3d geometry you’ll want to enable/disable depth write and test as required.

EDIT: here’s a better benchmark. I’m getting 3 million tris at 60 FPS. EDIT it’s 2 million textured with alpha testing

This is a 75px triangle (running at 1280×720 default window) benchmark to see how your system compares to PS2 running BooBoo. You should probably texture the triangle to get a more accurate result. I get about 900,000 textured and 1.2 million untextured per frame.

EDIT: PlayStation 2 claims max 16 million per second, that’s 266,000 per frame.

var tris
= tris 3000000

var font
= font (font_load "font.ttf" 32 1)

var vertex_buffer
call load_vb

set_projection (identity 4) (ortho 0 640 360 0)

function load_vb
{
	var verts faces colours normals texcoords

	var i
	for i 0 (< i tris) 1 next
		var x y
		= x (rand 0 1280)
		= y (rand 0 720)
		vector_add verts x y 0
		vector_add verts (+ x 6) y 0
		vector_add verts x (+ y 6) 0
		vector_add faces (+ (* i 3) 0) (+ (* i 3) 1) (+ (* i 3) 2)
	:next

	= vertex_buffer (create_vertex_buffer (@ verts) (@ faces) (@ colours) (@ normals) (@ texcoords) tris TRUE)

        vector_clear verts
	vector_clear faces
}

function draw
{
	enable_depth_test TRUE
	enable_depth_write TRUE
	draw_vertex_buffer vertex_buffer
	enable_depth_test FALSE
	enable_depth_write FALSE

	font_draw font 255 255 0 255 (string_format "%(.0f)" tris) 5 50
}

function event type a b c d
{
	if (== type EVENT_KEY_DOWN) key
		if (== a KEY_UP) up (== a KEY_DOWN) down
			= tris (+ tris 100000)
			destroy_vertex_buffer vertex_buffer
			call load_vb
		:up
			if (> tris 100000) go
				= tris (- tris 100000)
				destroy_vertex_buffer vertex_buffer
				call load_vb
			:go
		:down
	:key
}

• Add VBOs for create_vertex_buffer (optional last boolean parameter) for greater speed
• Fix winding order of faces in lit3d, 3dcube and DOOMED examples now that we are culling backfaces
• vector_clear now free memory not just vec.clear()