dazed
New Member
Posts: 9
|
Post by dazed on Jan 28, 2015 1:50:48 GMT
A while ago, I checked out Ness Engine and I liked what you did with it. I felt that it was very innovative and gives a more simplistic approach to creating more complex games in SDL easier. The biggest downfall to this project is that it is a windows only library if you will. I think it would be a bit more feasible for wider usage if you had dev libraries available for other IDE's such as C::B. This would also help with cross platform capability which I feel is the reason I choose a library. The ability to write code on lets say, Linux then compile with little to no problems on widows or Mac is definitely a big plus. I understand this is a hobby for you and completely understand if you say no.
On another side note, I saw that there was two threads asking for other features or capabilities. The threads in question were asking about networking and sound. I personally think it would be a good idea to put a link to a couple libraries in the tutorial area somewhere? My suggestions would be SDL libraries being preferred. The two being SDL_mixer (sound) and SDL_net (networking) and that would prevent people from asking such questions while steering them in some direction.
EDIT: I just realized that you had Linux and Mac TBD on the downloads page. If you already had the first planned or ruled out, you can ignore it.
|
|
|
Post by Admin on Jan 29, 2015 8:16:24 GMT
hi Dazed, thank you Linux and MAC are TBD for a long time (the download page tbd is an annoying reminder I put for myself ), however I currently put Ness-Engine on temporary hold, until I finish some other projects and businesses I have (I hope the engine is ready enough to be used as it is). you are also right about the sound and networks tutorial links, this is something I can do sooner. PS did you try to compile it for linux / mac? did you see anything in the code that prevents it? thanks!
|
|
dazed
New Member
Posts: 9
|
Post by dazed on Jan 29, 2015 11:05:12 GMT
I did have a compiled and working version for linux a while back. For me there weren't too many tweaks to be made, mostly just bugs in the version of gcc i was using. Was easily resolved by changing gcc versions. I'm not sure how solid it was, but it worked from what I could tell.
|
|
|
Post by Admin on Jan 30, 2015 12:18:09 GMT
Cool, good to know.
|
|
dazed
New Member
Posts: 9
|
Post by dazed on Feb 3, 2015 9:30:17 GMT
Okay, so I am working on compiling on C::B (on windows but will also be able to compile on linux). I am running into quite a few errors that I don't remember encountering last time around. The errors are things that are VS specific.
My first question is why did you use _itoa_s instead of something like sprintf in color.h. Another question about that line is why did you multiply the value by 255.0f? (any value greater than one would cause the color to be wrong[didn't look too far into this one, just figured id ask before i go digging to find out why])
Apart from that, everything else up to the nope api was pretty easy to convert to c++ standard. Just simple things. Working on making my way through that now.
-EDIT- Done, now I am going to go through and try out the tutorials to see if the dll works.
|
|
|
Post by Admin on Feb 3, 2015 11:34:34 GMT
wow that's awesome! can you send me the repairs you've made to make it compile? or is it just the itoa thing? why I used __itoa_s instead of sprintf: actually I though itoa was a standard, just like atoi. now that I checked I was quite surprised to see that its not I will fix it in next version (that will hopefully come out soon when I get some time), and thank you for the tip! why multiply by 255: the serialize/deserialize functions are used to save/load colors and vectors into files (or transfer them as buffers) when I serialize color I want to store every color component in a single byte (and not 4 bytes), so I multiply it by 255.0f and convert it to byte. if its larger then 1.0f it will wrap around, but that's how colors above 1.0f behave anyway. when I deserialize color component I divide by 255.0f and convert to float. "everything else up to the nope api was pretty easy to convert": - by nope api you mean just the itoa_s? or are there other things? PS to test it you can run the example codes, and if you want I can send you more complicated demos that don't appear on the site you can test (and also use if they interest you) thanks!
|
|
|
Post by silderan on Feb 3, 2015 13:27:00 GMT
Maybe doesn't matter, but a 0.0 to 1.0 (float) value cannot fit into a single byte. At least, you'll lose precision, and value may change because of base10<->base2 conversions. For example. 0.121 will become to 30.855. And 30 / 255 == 0.11765 (without the base10<->base2 related problems) BTW: Great job with C::B. In this computer that I'm right now, cannot install VS2013 and I prefer C::B instead VS2010 cose it's much more lighter
|
|
dazed
New Member
Posts: 9
|
Post by dazed on Feb 3, 2015 15:20:42 GMT
Ok so color value is stored as a float, that makes more sense. The only downfall i see of that is there would be slight loss of data with the calculation due to losing any decimal point value that may have been left over.
lol, didnt realize i typed nope, its supposed to read node, there was 2 sort methods in there where you compared a non const with a const and that usually only compiles in VS.
another slight modification i made was due to a gcc bug that has been known for quite some time (and sadly never fixed) which had to do with not dealing with a lambda properly.
The define macro for what im assuming is text replacement on points and colors needed a slight mod to compile. I'm assuming that its another thing VS does on its own.
had to include <typeinfo> in color.h for type_info to compile also had to change "string.h" to <string.h> for memcmp to compile (not sure why)
Also I had to declare a couple of node pointers const due to type mismatches
thats pretty much all that was needed to compile, now i just have to get it working. It detects it just fine and i can see all the methods available to me in the program, but upon compiling i get "function marked dllimport"
I probably wont be finished with the port until later tonight/tomorrow because i need some sleep and i have some family matters later today. I'll let you know if i get it working. If I do, I would love to test using more advanced demos once it passes the test for the demos given.
|
|
dazed
New Member
Posts: 9
|
Post by dazed on Feb 3, 2015 15:23:07 GMT
Quick question, when you compiled the dll in VS, are the functions exported by name or ordinal?
|
|
|
Post by Admin on Feb 3, 2015 17:50:25 GMT
silderan: yeah I'm aware of that but its not a problem really since monitors are in the range of 0 to 255 anyway (and also SDL works with byte colors), so the color 0.1 and 0.10001 are actually the same. working with float colors have the advantage of easy math calculations (especially multiply and division operators), but it can produce values that get rounded to fit into byte. but I like how you notice all these small details dazed: I export them by name (https://github.com/RonenNess/ness-engine/blob/master/source/NessEngine/exports.h) regarding your other comments on how to compile to linux, is there a chance you could send me the modified files by email (ronenness@gmail.com)? it will save me time and I want to make sure I won't miss anything. thanks
|
|
dazed
New Member
Posts: 9
|
Post by dazed on Feb 4, 2015 6:53:51 GMT
I sent you an email with the modified files, I believe thats all of them.
|
|