So what happened today? Honestly a date tonight :) and ..
I did take a look last night at the iphone project, and its getting closer to working ... although it seems pretty complex to make CMake build the projects.
I'm also most, as soon as I have something working I will publish the results, and probably switch to getting the Android working.
Why not finish the project, and then get all the ports working ????
I really want to be able to ship on IOS, and Android at the same time, and working on getting both working at the beginning means I should have a good understanding day by day of what I can, can't do on each platform.
This should be the total dev time should be less, once I get going, but I guess we will get to see.
Hoooky - or skipping out to build games
Friday, July 28, 2017
Thursday, July 27, 2017
Full Circle
Saw an interesting post yesterday:
How to make games – Making the transition from business apps and web development into gaming
I have pretty much done the full circle, I started out in 8bit games (z80, 6502), made the transition to 16/32bit (68000/Ricoh 5A22).
Then I kind of got serious, although mostly close to pixels, I worked on some pretty serious, and interesting business apps.
No both here, and probably in my professional life I'm going to end up working back in games.
I'm going to hold off on the details for the moment, because I don't want to count my chickens before ... :)
How to make games – Making the transition from business apps and web development into gaming
I have pretty much done the full circle, I started out in 8bit games (z80, 6502), made the transition to 16/32bit (68000/Ricoh 5A22).
Then I kind of got serious, although mostly close to pixels, I worked on some pretty serious, and interesting business apps.
No both here, and probably in my professional life I'm going to end up working back in games.
I'm going to hold off on the details for the moment, because I don't want to count my chickens before ... :)
Wednesday, July 26, 2017
Blogging
I want to try and make 1-2 posts every day, I think some days, I'm going to make more.
I would also like to fix the way things look, to make everything more readable.
But I also want to get a build working for IOS ...
I would also like to fix the way things look, to make everything more readable.
But I also want to get a build working for IOS ...
So Whats changed?
I wanted to test the include headers, to make sure I was getting the openGL, openGLES includes.
The OSX version will use openGL, but IOS/Android uses openGLES. I don't want this difference to be all through the code, to it will be localized into the view code, with an abstraction that handles the kinds of objects I want to render.
There is a cost for this layer, but if you get things right, its minimal, and the benefit in game code, of not having to worry about the target means I could easily port to other platforms at a later stage.
I builts a PS2/Gamecube/PC(openGL) engine, that I ported to XBox(DirectX) in around 2 weeks. It supported fully skinned 3D characters, and a full scene graph. This project is just going to be 2D, so I'm not very worried.
As part of the testing, I some quick window init, wait for key code. Its very temporary, but allowed me to test everything was compiling, linking, and running:
So here is the screen shot, I know its not very impressive, but its only the start.
I wanted to test the include headers, to make sure I was getting the openGL, openGLES includes.
The OSX version will use openGL, but IOS/Android uses openGLES. I don't want this difference to be all through the code, to it will be localized into the view code, with an abstraction that handles the kinds of objects I want to render.
There is a cost for this layer, but if you get things right, its minimal, and the benefit in game code, of not having to worry about the target means I could easily port to other platforms at a later stage.
I builts a PS2/Gamecube/PC(openGL) engine, that I ported to XBox(DirectX) in around 2 weeks. It supported fully skinned 3D characters, and a full scene graph. This project is just going to be 2D, so I'm not very worried.
As part of the testing, I some quick window init, wait for key code. Its very temporary, but allowed me to test everything was compiling, linking, and running:
void test(void)
{
if (SDL_Init(SDL_INIT_EVERYTHING) != 0)
{
std::cout << "ERROR SDL_Init" << std::endl;
}
// Create window
SDL_Window * lWindow = SDL_CreateWindow("Defender", // window title
SDL_WINDOWPOS_CENTERED, // x position, centered
SDL_WINDOWPOS_CENTERED, // y position, centered
640, // width, in pixels
480, // height, in pixels
SDL_WINDOW_OPENGL // flags
);
SDL_Event lEvent;
bool lRunning = true;
while (lRunning) {
while (SDL_PollEvent(&lEvent))
{
switch (lEvent.type)
{
case SDL_WINDOWEVENT:
{
}
break;
case SDL_KEYDOWN:
{
if (lEvent.key.keysym.scancode == SDL_SCANCODE_ESCAPE) {
lRunning = false;
}
}
case SDL_QUIT:
lRunning = false;
break;
}
}
}
}
So here is the screen shot, I know its not very impressive, but its only the start.
Tuesday, July 25, 2017
Of Religion
I have a little experience in development, more than the age of most developers coming out of school.
I don't say I'm right, but all the best programmers I have worked with, tend to be religious about certain aspects of the code they write. This doesn't say they are right, but one thing is clear, consistency really does go along way to help with building code that works.
Normally when I interview, I like to see a code sample, normally before a second interview, I try to review it with the people I work with, and I try to then review it with the person I'm interviewing.
For me this provides a great insight into the person, and their ability to handle big problems. Making sure your code is clean, and regular, removes the worry of trying to find problems in it. As often mistakes will be very visible just through the irregularities in the pattern in the code.
An ex partner that couldn't code, could always tell when I was looking on my code, or someone elses, just by the style from across the room.
Again, I'm not trying to say my style is right, but I find someone that doesn't have a style, will write code that will be harder to maintain, and keep functional. When everything is built with the same pattern, finding something new becomes easy, because you already know the pattern, like using the index in a book.
So I guess we get onto some things I like to do to keep my code clean:
All header files have:
I tend to try and keep code in modules, with using a module/module.h include file to pull in everything I need.
I generally try and keep one class per file, although I do make exceptions where I think it makes sense, or keeps a piece of functionality hidden at the level it needs to operate.
Scope is very important to me. I use in/out as prefixes on function parameters, I use the l prefix to define locals, and the m prefix to define members. This allows me to quickly see at what level I'm playing.
I like singletons, and generally use the s prefix to hold the member.
I guess thats its for now, as we code, I guess we will get into more style issues.
So I have added some lines to the CMakeLists.txt
and now
I don't say I'm right, but all the best programmers I have worked with, tend to be religious about certain aspects of the code they write. This doesn't say they are right, but one thing is clear, consistency really does go along way to help with building code that works.
Normally when I interview, I like to see a code sample, normally before a second interview, I try to review it with the people I work with, and I try to then review it with the person I'm interviewing.
For me this provides a great insight into the person, and their ability to handle big problems. Making sure your code is clean, and regular, removes the worry of trying to find problems in it. As often mistakes will be very visible just through the irregularities in the pattern in the code.
An ex partner that couldn't code, could always tell when I was looking on my code, or someone elses, just by the style from across the room.
Again, I'm not trying to say my style is right, but I find someone that doesn't have a style, will write code that will be harder to maintain, and keep functional. When everything is built with the same pattern, finding something new becomes easy, because you already know the pattern, like using the index in a book.
So I guess we get onto some things I like to do to keep my code clean:
All header files have:
#pragma once
#ifndef _MODULE_FILE_H_
#define _MODULE_FILE_H_
#endif // _MODULE_FILE_H_
As guards to make sure they are only included once.I tend to try and keep code in modules, with using a module/module.h include file to pull in everything I need.
I generally try and keep one class per file, although I do make exceptions where I think it makes sense, or keeps a piece of functionality hidden at the level it needs to operate.
Scope is very important to me. I use in/out as prefixes on function parameters, I use the l prefix to define locals, and the m prefix to define members. This allows me to quickly see at what level I'm playing.
I like singletons, and generally use the s prefix to hold the member.
I guess thats its for now, as we code, I guess we will get into more style issues.
So I have added some lines to the CMakeLists.txt
include_directories(
${SDL2_INCLUDE_DIR}
${CMAKE_CURRENT_SOURCE_DIR}
)
#include
still allows main.cpp to build.The First Build
Ok, so I'm playing around with laying out the project, seems I'm learning as I go:
This is the layout I have picked for the moment. The root give a place for the different builds, only source is under source control (git). core is currently empty, but will provide a location for core files, and there will be other folders to hold the display driver, sprites, audio.
Ok, so what did I build:
so to build, move into build_osx folder and:
once its finished:
and you should build the executable for your mac.
project root
+ build_osx
+ source
+ core CMakeLists.txt main.cpp This is the layout I have picked for the moment. The root give a place for the different builds, only source is under source control (git). core is currently empty, but will provide a location for core files, and there will be other folders to hold the display driver, sprites, audio.
Ok, so what did I build:
#include
int main(int /*argc*/, char * /*argv*/[])
{
printf("Defender\n");
return 0;
}
not a lot, but its a start, really just to make sure that the CMakeLists.txt file was correct, and that was:
cmake_minimum_required(VERSION 3.9)
project(defender)
###############################################################################
# increase warnings
###############################################################################
# Bump up warning levels appropriately for clang, gcc & msvc
# Also set debug/optimization flags depending on the build type. IDE users choose this when
# selecting the build mode in their IDE
if (${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU" OR ${CMAKE_CXX_COMPILER_ID} STREQUAL "Clang")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -pedantic -std=c++11")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_DEBUG} -g")
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE} -O2")
elseif (${CMAKE_CXX_COMPILER_ID} STREQUAL "MSVC")
if (CMAKE_CXX_FLAGS MATCHES "/W[0-4]")
string(REGEX REPLACE "/W[0-4]" "/W4" CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
else()
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
endif()
endif()
###############################################################################
# Platform Details
###############################################################################
###############################################################################
# OSX 10.12 - current dev platform
###############################################################################
if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
# remove the warnings
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-gnu-anonymous-struct -Wno-nested-anon-types")
find_library(SDL2 NAMES SDL2)
message(${SDL2})
find_library(OPENGL NAMES OpenGL)
message(${OPENGL})
set(PLATFORM_LIBS
${SDL2}
${OPENGL}
)
###############################################################################
# OSX 10.12 - current dev platform
###############################################################################
else()
message("Bad platform")
endif()
###############################################################################
# Handle includes
###############################################################################
include_directories(
${SDL2_INCLUDE_DIR}
)
###############################################################################
# Source files
###############################################################################
file(GLOB MAIN_FILES
"${CMAKE_CURRENT_SOURCE_DIR}/*.h"
"${CMAKE_CURRENT_SOURCE_DIR}/*.cpp"
)
###############################################################################
# executable
###############################################################################
add_executable(defender
${MAIN_FILES}
)
target_link_libraries(defender ${PLATFORM_LIBS})
Its a lot, but it handles linking the SDL2 and openGL libraries into the final executable.so to build, move into build_osx folder and:
cmake -G "Unix Makefiles" ../sourceonce its finished:
makeand you should build the executable for your mac.
>defender
Defender
>
and its working. Not bad for half a days work :)
Tools:
My dev machine is a 2010 Macbook Pro, running macOS Sierra version 10.12.6, It's on its 2nd battery, 3rd drive (it currently has a 2TB ssd), but it actually still works pretty well. It seems we have passed the point where a faster machine really brings anything new, unless you are playing with really heavy compute applications like AI.
The hardest part of game development is the tweaking to get the feel just write. This really means you need to keep the cycle between code change, and play testing as short as possible. One way to do this is to be able to build, and run on the same platform, and then to post target. This is my plan. For this reason I will use SDL2-2.0.5 as my application framework. It should be then a simple job to port to IO/Android from there.
For any project source control is a must. I will be using git-2.13.1.
As an editor I'm going to start out with Microsoft Visual Studio Code, I also have Xcode (8.3.3) installed, but I don't really like it, so we will see. I hope to be able to build everything from CMake, perhaps at some point even on a build server.
I have adapted a strategy of trying to be careful about versions, I generally don't update anything, until I'm ready to grab all the latest versions of everything. This means I can keep down things that might cause a change in stability down to a minimum, and just spend a day debugging everything broken by a version change in libraries.
Subscribe to:
Posts (Atom)
