![\"The](\"http:\/\/www.coolbasic.com\/common\/images\/archives\/2014\/08\/very_temporary_editor.png\")
<\/p>\nToday I\u2019m going to talk about some old stuff. Don\u2019t worry though, most of you haven\u2019t seen it yet. A year ago, at our traditional summer meeting, I demoed some very early and experimental CoolBasic builds. The reason I want to show code and screens this old, is so that it\u2019s easier to explain about how things have since changed in the future coming blog posts.<\/p>\n
Back in 2013 I actually had a working environment that consisted of a code editor, CoolBasic compiler, and a debugging runtime. You could write CoolBasic code, pass it to the compiler and finally execute it. It couldn\u2019t render game graphics or play sounds, but the very basic text input and output was in place. At that time I focused on code execution rather than game libraries. Control structures, strings, arrays, types, operators, all that kind of stuff. As a result, the demo was probably very boring to watch, but hey, at least it was executing something!<\/p>\n
The compiler was naturally the number one priority to get done. In refreshment, it\u2019s written in C#, running on .NET CLR and Mono, and is a standalone console application so it can be called from anywhere. It wasn\u2019t feature complete back then (for example, Select…Case was missing,) but it could handle most control structures and generate the final bytecode.<\/p>\n
Compilers aren\u2019t very exciting, though. All you need to know is it\u2019s now faster, more feature-rich, and hasn\u2019t got a function limit.<\/p>\n
<\/p>\n
Before you go to the forums and start complaining about how awful it looks, mind the window title. Guess why it\u2019s called \u201cVERY TEMPORARY EDITOR\u201d. The caps are intended. This will *not* be the editor that will ship – don\u2019t worry. I promise.<\/p>\n
In short, I just wanted to test a)<\/strong> how easy it is to integrate the compiler into an IDE, and b)<\/strong> could I perhaps use AvalonEdit<\/a> as the editing control as opposed to the commercial Actipro SyntaxEditor<\/a>. I\u2019m already quite familiar with the Actipro component (had a chance to use it in a work project) and I know it is the state-of-the-art option, but perhaps that would be a little bit of an overkill for my purposes.<\/p>\n As it turns out, AvalonEdit is just perfect, at least for the starters; I can always upgrade to Actipro later. AvalonEdit offers configurable syntax highlighting out of the box, supports code completion popups, and is generally fairly extendable. Syntax highlighting definition is loaded from an external XML file, and the list of commands provided by the game engine is imported from a special \u201cframework definition file\u201d that I can generate automatically off a compiled executable or DLL (via reflection.)<\/p>\n It was pretty easy to invoke the compiler, have its output written in a textbox, and parse off any errors it would report. All in all, a successful little test editor.<\/p>\n That\u2019s not a real game engine. It\u2019s actually just a normal WPF application powered by the new Cool VES virtual machine. In fact, the only available commands are For this reason there are some debugging features available. At any time, I can click this cute pause button:<\/p>\n This will halt the virtual machine that\u2019s executing the code. While paused, this UI becomes available:<\/p>\n This view lists all functions and variables and their types. Symbol information is needed for a number of reasons. Firstly, the debugger can emit more meaningful call stacks when the functions\u2019 names are known. Secondly, the runtime can perform proper clean-up when returning from a function as it knows which resources are stored in heap.<\/p>\n This listing represents the current program in its \u201cdisassembled\u201d form. Here I can see that the program was decoded properly and matches with what the compiler spat out.<\/p>\n Remember how Interestingly, also strings<\/strong> are managed resources and they, too have handles that are manipulated every time a string is stored in and consumed off the stack.<\/p>\n If I want to see the low-level state about the executing program, this is the view I\u2019m interested in. I can inspect the values of each variable, for each function within the call stack. This information, of course, would be presented in a more intuitive way in a real debugger.<\/p>\n So that\u2019s how things were a year ago. Nowadays the compiler is pretty much feature complete, and the real code editor is in the works. I also did some engine experiments based on the DirectX10 interface (initially on DX11, but for whatever reason DirectWrite that I use for text rendering isn\u2019t easily usable in it.) More on these topics in future coming posts.<\/p>\n","protected":false},"excerpt":{"rendered":" Today I\u2019m going to talk about some old stuff. Don\u2019t worry though, most of you haven\u2019t seen it yet. A year ago, at our traditional summer meeting, I demoed some very early and experimental CoolBasic builds. The reason I want to show code and screens this old, is so that it\u2019s easier to explain about […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[5,6,7],"_links":{"self":[{"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/posts\/394"}],"collection":[{"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/comments?post=394"}],"version-history":[{"count":7,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/posts\/394\/revisions"}],"predecessor-version":[{"id":401,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/posts\/394\/revisions\/401"}],"wp:attachment":[{"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/media?parent=394"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/categories?post=394"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.coolbasic.com\/blog\/wp-json\/wp\/v2\/tags?post=394"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}A VERY TEMPORARY Runtime<\/h2>\n
![\"The](\"http:\/\/www.coolbasic.com\/common\/images\/archives\/2014\/08\/very_temporary_runtime_0.png\")
<\/p>\nPrint<\/code>, Input<\/code>, and Timer<\/code> (for benchmarking.) The intention was to establish a simple \u201cconsole\u201d which would provide basic input and output so that I could test that the virtual machine doesn\u2019t corrupt the virtual stack or leak memory at any point.<\/p>\n<\/p>\n
Metadata: symbols<\/h6>\n
![\"Debug](\"http:\/\/www.coolbasic.com\/common\/images\/archives\/2014\/08\/very_temporary_runtime_1.png\")
<\/p>\nBytecode<\/h6>\n
![\"Debug](\"http:\/\/www.coolbasic.com\/common\/images\/archives\/2014\/08\/very_temporary_runtime_2.png\")
<\/p>\nManaged resources<\/h6>\n
![\"Debug](\"http:\/\/www.coolbasic.com\/common\/images\/archives\/2014\/08\/very_temporary_runtime_3.png\")
<\/p>\nLoadImage<\/code> would return a handle that you\u2019d then store into a variable for later use? These handles are called \u201cResources\u201d internally in Cool VES. For more efficient memory management Cool VES keeps a list on what has been loaded. It\u2019s not a real (unmanaged) memory pointer, but a reference to an internal object that also contains metadata of that object.<\/p>\nCall stack and locals<\/h6>\n
![\"Debug](\"http:\/\/www.coolbasic.com\/common\/images\/archives\/2014\/08\/very_temporary_runtime_4.png\")
<\/p>\n