Posted: 27th Nov 2014 12:16
r am I missing the point?


On PC (I can't speak for Mac), any game will let you select a resolution from all the fullscreen resolutions your system supports. So say you have a 1080p monitor and you're playing BF4. Also say it's not running well and you want to lower the resolution; your system will almost certainly also support 720p, so you select that. You can now play at a much higher FPS, and because 720p is the exact same aspect ratio as 1080p you don't have distortions.

The point is that in any PC game you have the option of choosing from any supported resolution rather than being limited to the screen's current res.
Posted: 27th Nov 2014 13:09
Another option could be to only change the render target resolution.

First this would also make using the Occulus Rift usable in the future and also i have seen this in other games. Newest example where i have seen such an option is Dragon Age: Inquisition where you can change the render target resolution instead of the display resolution.
Posted: 27th Nov 2014 13:56
Clonkex - I do know how to iterate DEVICE_CAPS etc - but the situation is slightly more complicated than you suggest, because the refresh rate has to be taken into account, among other things.

http://msdn.microsoft.com/en-us/library/windows/desktop/ee417025%28v=vs.85%29.aspx

What's relevant here to AppGameKit is being able to resize the back and front buffers. I think Paul took care of this.
Posted: 27th Nov 2014 14:05
The DrawLine / box / elipse commands are NOT scaled, and appear as ultra thin lines with their coordinates often randomly placed, if you run the app in a higher resolution that you designed it for.. they are useless for anything else than drawing on an image, and grabbed as a sprite that scales.

The text and sprites are also scaled without becoming blocky, and this produces a horrible look... I wish you could make a game for low res, and it would just scale on higher res, without the pixels getting smoothed out.

Using the percentage system is only for the clinically insane coders...
Posted: 27th Nov 2014 14:09
@Impetus - You want magnified sprites to stay blocky? Use SetImageMagFilter(img,0) on it
And % is for insane? Now I have an excuse muahahaha!

@Jim - I see your point about scaling. I have to think about that! Now if AppGameKit would just not stretch on window maximize
Posted: 27th Nov 2014 14:17
OS is not possible without a Mac to access the keychain for signing the app. Marmalade can make test IPAs under Windows, but you can't distribute those IPAs on the App Store without a Mac:


Seriously ... you quote the text that exactly tells you that you CAN do this but you didn't even read those 4 lines of text??

You only need a Mac to upload a final build (which CAN be build and signed on Windows) to the store but that's something very different and a situation where you, for sure, could use a rented Mac in the cloud every once in a while. But your day to day development can be done completely on Windows.

In the end I don't really mind, I own a license for all targets on Marmalade as well as a Mac and AppGameKit 2 and Monkey and much more It was just meant as an information to show that it actually is possible and, IMO it's a great feature. But given Visual Studio 2015 seems to add support for Android and iOS development too, this might enable TGC an easy way to support iOS builds in later version/updates too.
Posted: 28th Nov 2014 1:37
Clonkex - I do know how to iterate DEVICE_CAPS etc - but the situation is slightly more complicated than you suggest, because the refresh rate has to be taken into account, among other things.


I think we're both missing each other's points and I for one have completely forgotten what I was originally pointing out. *facepalm* I'm just going to drop it because I have no idea what I'm arguing for

I see your point about scaling.


You do?? I don't even remember what MY point was...

You only need a Mac to upload a final build (which CAN be build and signed on Windows) to the store but that's something very different and a situation where you, for sure, could use a rented Mac in the cloud every once in a while. But your day to day development can be done completely on Windows.


You are of course correct, and I'm sure TGC will take your suggestion under advisement, but getting it signed automatically on Windows is fairly fiddly and complicated AFAIK, so we may never see that happen. Still, they got Android working from the IDE, so who knows?
Posted: 28th Nov 2014 4:14
Types with functions would be a huge step. You could do it without too much syntactical/compiler changes by something like the ideas below. All it ends up being is a syntactic rewrite of a function call, if you don't use subclasses. Obviously the compiler needs to know what the type is of the object it is acting on but it must know that anyway.

+ Code Snippet
type demotype
<stuff>
endtype

then

function method_dosomething_demotype(self ref as demotype, param1)
<stuff involving self>
end

(or even function demotype:dosomething(param1) with a little bit of sugar)

then you could have:

test as demotype
..
..
test:dosomething(42)

this last line is just a function call - it would just be syntactic sugar for

method_dosomething_demotype(test,42)



this would give you a very simple OOP system. Then you have subclassing, which could be done via types within types messily.

+ Code Snippet
type subtype
  oldclassstuff as demotype
  (new members here) 
endtype

so that if the syntactic sugar failed (e.g. there was no subclass subtype method donothing) it looked in the superclass and applied the subclass method of demotype to the oldclassstuff member.


What you don't have is any virtual functions/polymorphism type stuff. This may not even be possible in the bytecode which looks to be entirely static in nature. A basic (ahem) question is can the system do call func$(a,b,c) ?

And regular expressions would be nice. Maybe not bother with the whole lot - lua has a simplified version which works for most code requirements.

I would think it's part of the lua library code (e.g. it's written in C) so you might just be able to use it as it is with a bit of tweaking. lua is designed to be embedded in other programs without doing the license-virus thing that O/S code often does. Could be new facilities for pretty much no work - pass it two strings and an array of strings for the return groups and return a "boolean".
Posted: 28th Nov 2014 13:09
+1 for lua support.

With lua support given I could finally make my dream of a spaceship game where you can program the engine, weapons, shields, etc by yourself come true
Posted: 28th Nov 2014 16:01
Multicoder, why would that not be possible without lua?
Posted: 28th Nov 2014 19:14
I've been calling for Lua for years, to no avail. It would massively improve the power of T1 and T2.
Posted: 28th Nov 2014 20:36
I really meant just pinching the lua pattern matching library. I think TGC want to stick with BASIC rather than lua.
Posted: 28th Nov 2014 22:42
VS2013 support for T2, since now VS2013 is free so might as well drop support for older versions and just make VS2013 libs
Posted: 28th Nov 2014 23:52
baxslash, I don't want to invent an own scripting language and write an interpreter for it.
I would love to use an existing language that "everyone" knows. If there are other languages which can be "injected" into a game made with agk T1, please let me know
Mod support would also be easier to do.
Posted: 29th Nov 2014 14:30
I'd like to see some improvements to the EditBox.

First, The SetEditBoxFontImage command needs an overhaul. From what I can see, it's not possible to specify character spacing, etc. of the font in the EditBox.

Second, when running on a PC/mac with a keyboard, the EditBox should behave more like standard OS edit controls:

- select text by dragging
- select a word by double-clicking
- select all (ctrl+A)
- overtype
- copy/cut and paste

These features could be switched off and on in code.

BTW, I am LOVING alpha 9. Very nice work.

Thanks,

James
Posted: 29th Nov 2014 23:48
It would be cool to have the C# .dll lib to be updated along with the AppGameKit 2.0 so people with .NET can use AGK. I could use this in many different ways! since C# is easier then C++, but yet is not the BASIC coding with AppGameKit, there are many possibilities with ease.
Posted: 30th Nov 2014 2:07
@bjadams
VS2013 support for T2, since now VS2013 is free so might as well drop support for older versions and just make VS2013 libs


This is already in the Steam version, and will be coming to non-Steam soon (I guess with the next update.)
Posted: 5th Dec 2014 19:57
@ Naphier,

Sooooo. Where are we with this....?
Posted: 5th Dec 2014 20:00
Busy. Not sure of AGK's stance on the whole thing.
Does it really matter? I don't think Paul will have a chance to consider this stuff until they're out of alpha.
So why not just leave it open until then?
Posted: 6th Dec 2014 18:57
I want to be able to specify port for HTTP connection.