tanis2000

package;


import openfl.display.Bitmap;
import openfl.display.BitmapData;
import openfl.display.Sprite;
import openfl.display.Graphics;
import openfl.display.CapsStyle;
import openfl.display.JointStyle;
import openfl.display.LineScaleMode;

tanis2000

class ParallaxPostProcessor : PostProcessor
	{
		private Effect _effect;
		private Texture2D _texture2D;
		private Camera _camera;

		public ParallaxPostProcessor(Camera camera, Texture2D texture2D)
		{
			_camera = camera;
			_texture2D = texture2D;

tanis2000

sampler TextureSampler : register(s0);
float2 ViewportSize;
float4x4 ScrollMatrix;

void SpriteVertexShader(inout float4 color : COLOR0, inout float2 texCoord : TEXCOORD0, inout float4 position : POSITION0)
{
    // Half pixel offset for correct texel centering.
    position.xy -= 0.5;
 
    // Viewport adjustment.

tanis2000

sampler TextureSampler : register(s0);

struct VertexShaderInput
{
	float4 Color: COLOR0;
	float2 TexCoord : TEXCOORD0;
	float4 Position : SV_Position0;
};

struct VertexShaderOutput

tanis2000

This is an answer to the great answer that @delanee gave me about Haxe and optimizations that can be found here: https://github.com/delahee/haxe.opt/blob/master/answer_to_at_santinellival.md

Thanks for the paper. There's a lot to think ad talk about.

I investigated Haxe due to the language having tons of interesting features and its great portability. I tried many frameworks like OpenFL, Kha, Lime, HaxeFlixel, HaxePunk, Luxe and many more to end up to deciding to skip Haxe as a whole for the time being. As I anticipated to you, my main issue was with hxcpp's garbage collector. Most frameworks aren't made for mobile or just aren't as optimized as they should be for real production work.

I see that the inline function new construct is probably going to be a blessing for those like me trying to squeeze out performance, but I feel that the whole Haxe ecosystem is still way behind. You guys at Motion Twin know Haxe inside out and have been using it for a long time. But for newcomers like me it's just a bumpy ro

tanis2000

#region Using Statements
using System;

using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Storage;
using Microsoft.Xna.Framework.Input;

#endregion

tanis2000

sampler TextureSampler : register(s0);

struct VertexShaderInput
{
	float4 Color: COLOR0;
	float2 TexCoord : TEXCOORD0;
	float4 Position : SV_Position0;
};

struct VertexShaderOutput

tanis2000

#include <hxcpp.h>

#ifndef INCLUDED_haxe_io_Bytes
#include <haxe/io/Bytes.h>
#endif
#ifndef INCLUDED_lime_graphics_Image
#include <lime/graphics/Image.h>
#endif
#ifndef INCLUDED_lime_graphics_format_BMP
#include <lime/graphics/format/BMP.h>

tanis2000

package lime.graphics.format;


import haxe.io.Bytes;
import lime.graphics.Image;
import lime.math.Rectangle;


class BMP {
	

tanis2000

Let's say we have 2 pokemons of the same type. Their CP will depend on the following values:

• IV (IndividualStamina, IndividualAttack, IndividualDefense)
• CpMultiplier
• AdditionalCpMultiplier

These values, together with move types, weight, height are what makes your pokemon unique.

Mechanisms that change these values:

• IV are fixed since catching a pokemon and never change
• CpMultiplier seems to be fixed and never changes it depends on player level at the time a pokemon was caught (list is here https://docs.google.com/spreadsheets/u/1/d/1I0Kt_QblThH2rf7vdZOC2L1Nuf7Y1xx68j_KYwfcpXc/htmlview?sle=true#)